Findings from the GitLab pipeline excursion
: Deniz Aydin
Minutes: 6300
GitLab CI/CD instructions can be found here.
- You need to create a YAML file that specifies the things that need to happen during the build process. This includes stages (e.g. test, build, deploy, etc.), variables, jobs, scripts, and very importantly, docker containers that need to be used.
- Then, define a runner. Right now, we have a single runner defined at the project-level for the D & I project, registered on Spartan. In general, we would probably have them on one of our HCMC servers, and defined at the group-level (so all repos that belong to our unit can access the same runners).
- Runner needs to be configured using a .toml file and registered.
- The runner needs to have an executor selected during its configuration. I’ve opted for Docker as this gives us caching options, the ability to reuse the same build environment, and portability. Here are all the options. Shell is ill-advised as it poses a security risk.
- Using a handcrafted Dockerfile, I’ve spun up a new Docker container for this project. This container lives on DockerHub. The Dockerfile lives on Spartan.
- The YAML file build stages reference this particular Docker container.
Things that remain to be done:
- Check that cache is working as intended.
- Check the docker-autoscaler options. There is a massive thread on its current issues, so it’s questionable how successful this is going to be.
- Add log-parsing as a third build stage, aping Martin’s regexs used in current Jenkins builds.
- Check to see what happens if the runner is defined at the group level.
- Follow-up on GitLab Pages as an option for our outputs.