Stategy for continuous integration (CI)
Fast unit tests should already make it possible for everyone involved in the redesign to to run test locally on their developemt machine (!4 (merged)). But as a second line of defense it would be good to have the same tests running on GitLab runners whenever commits are pushed to a branch for which a MR is opened.
I naively created a new gitlab-ci.yml
file thinking I could quickly spin up a CI workflow... but it's not as straightforward as I thought.
Mainly because the tests have Nektar++ as a dependency. I've explored a few options:
- Run pipeline in a container based on the nektarpp/nektar docker image. However the image doesn't come with dev tools like cmake or GCC. because the default user is not root, the container must be run with
--user="root"
to install packages. Fine from the docker command line, but not clear to me if this is possible from GitLab. - Build Nektar++ and cache built libraries (cache the
dist/
directory). But two jobs (saybuild
andtest
) running on two different runners (sayliverpoolstreet
andwaterloo
) won't share the cache unless distributed cache is setup. Another option is to constrain the two jobs to the same runner, maybe using runner tags? - Install latest Nektar++ with
apt
from the Debian repo. I originally didn't go this way as it sounded expensive to install nektar++ for every job compared to having a cached build. But given the limitations above, this is starting to look like the way to go. - Pull image from local container registry. I can see that the main GitLab repo has a container registry accessible - could we do the same for this one?