Continuous integration tricks

This topic is a wiki page (you can edit it) to collect tricks for working with our gitlab continuous integration system.

Superbuild system

The CMB and aeva projects have many dependencies. The cmb-superbuild project exists to prepare them (and create packages for CMB and aeva). The dependencies are put in docker images (linux) and tarballs (macos, windows) that gitlab’s continuous integration system uses to test merge requests. Visit

https://gitlab.kitware.com/cmb/cmb-superbuild/-/pipelines

to see the list of pipeline runs. These runs include artifacts you can download that include log files (from the Build stage) and packages (from the Test stage). Each pipeline marked “Scheduled” is a nightly build that has an additional Update-ci stage that uploads test artifacts for use by gitlab-ci when building other projects.

Forcing a package upload

Each night, a scheduled CI job is run that builds and uploads packages. Normally, merging changes to the CMB superbuild does not upload any generated packages (to prevent wasted disk space and bandwidth). Sometimes, you make a change that warrants immediate package uploads (like fixing breakage that prevented uploads the night before or ensuring packages are viable before a formal release).

In that case, you can manually schedule a job by visiting this URL:

https://gitlab.kitware.com/cmb/cmb-superbuild/-/pipelines/new

Before clicking the “Run Pipeline” button, add a variable to the job with the name GIRDER_UPLOAD_ENABLE and a value of true.

Is it? I can’t see a way to edit it.

Try now

I may have missed it before. I guess I’m used to admin rights on the other Discourse instances; there’s a labeled Edit button rather than just a pencil icon in the expander at the bottom of the post (I get a labeled Admin icon on other instances).

Privacy Notice