Builders
Builders
This page describes how Cinc packages are built for each platform, for people maintaining or contributing to the build infrastructure. The supported platforms and the policy for adding and dropping them are on Supported platforms.
All builds run as GitLab CI jobs in the cinc-project group, on runners hosted by the Oregon State University Open Source Lab. Every builder first installs the omnibus toolchain, which provides the Ruby, compilers and packaging tools the product builds use.
Builders by platform
| Platform | Runs on | Runner tags | Provisioned by |
|---|---|---|---|
| Linux (AlmaLinux, Rocky, Debian, Ubuntu, Amazon Linux, SLES) | Docker containers on shared Linux runners | docker-x86_64, docker-x86_64-v3, docker-aarch64, docker-aarch64-v8.2-a, docker-ppc64le, docker-ppc64le-p9, docker-s390x, docker-riscv64 | docker-images (cincproject/omnibus-<distro>:<version>) |
| Windows | cincproject/omnibus-windows container (Server Core ltsc2022, process isolation) on a Windows Server VM in OpenStack | windows-docker; packages are tested on windows-x64-package-testing | docker-images omnibus-windows/ |
| macOS, Apple Silicon | Parallels VMs on Apple Silicon Macs, one VM per macOS version | macos-<version>-aarch64 | cinc-omnibus cookbook |
| macOS, Intel | VMware Fusion VMs on Intel Macs, one VM per macOS version | macos-<version> | cinc-omnibus cookbook |
| FreeBSD | VMs in OpenStack, one per FreeBSD major version | freebsd-<version> | cinc-omnibus cookbook |
| Cinc Server test hosts | Short-lived OpenStack VMs created with Vagrant for each test job | cincproject/vagrant image; jobs share openstack-1 to openstack-4 resource groups | the server and cinc-server repos’ Vagrantfile |
Linux container images
- The
cincproject/omnibus-*images are built in docker-images withdocker buildx bake. Each image runs the cinc-omnibus cookbook’s builder setup, so the container has the same packages and toolchain as a VM builder. - SLES images are built on SUSE’s free SLE Base Container Images (
registry.suse.com/bci/bci-base), which need no registration. When SUSE releases a new minor version (for example SLES 16.1), the image moves to it. - The omnibus toolchain itself is built on the plain distribution images (
almalinux:10,registry.suse.com/bci/bci-base:15.7, and so on), not on theomnibus-*images, so it only depends on what a fresh install provides.
Job and cache names
Package and test jobs are named package:<os>-<version>:<arch> and test:<os>-<version>:<arch>. A few names differ from the distribution name for historical reasons:
centos-<N>jobs build on AlmaLinux and publish toel/<N>.opensuse-<N>jobs build on the SLES images and publish tosles/<N>.
Adding a builder
- Check the new release is on endoflife.date and meets the add policy.
- Linux: add a target to the distribution’s
docker-bake.hclin docker-images and publish the image. macOS, FreeBSD: create the VM, converge it with the cinc-omnibus cookbook, and register a GitLab runner with themacos-<version>[-aarch64]orfreebsd-<version>tag. For FreeBSD, start at the release’s BETA. - Add the platform to omnibus-toolchain and release it, so
omnitruck.cinc.shserves a toolchain for the new version. - Add
package:andtest:jobs (pluscleanup:for macOS) and thedeploydependency in each product, then ship it in the product’s next release. - Update Supported platforms.
Retiring a builder
- Remove the platform’s
package:,test:andcleanup:jobs, thedeploydependencies and any cache keys from every supported release line. - Remove it from omnibus-toolchain.
- Once no supported line builds it, remove the docker-images target, or unregister the runner and shut down the VM.
- Update Supported platforms.
Keeping builders healthy
- Keep FreeBSD and macOS VMs on a supported point release of their OS. FreeBSD point releases go EOL a few months after the next one ships, even while the major version is still supported.
- Re-converge VM builders with the cinc-omnibus cookbook after OS or runner upgrades rather than changing them by hand.
- Rebuild the container images when their base images change, and pin products to a dated tag where they need a stable builder (as Windows does with
BUILDER_IMAGE_TAG).