Clean up gitlab-ci.yml and add trigger for new lisp implementation versions

Eric Timmons requested to merge 66-ci-upgrades into master

This is currently a draft as I need to do a little bit more testing on the cl-docker-images side that may necessitate a few changes here as well.

This tidies up our existing CI pipeline by:

  • Removing the jobs that used Makefile-lisp-scripting. As far as I can tell, they were never used after the initial merge. I would be happy to readd if and when we have a solid use case for them as part of CI. Otherwise, I'm afraid they'll just bitrot.

  • Switch to matrix specification of jobs. This results in a more compact and clearer yml file, but comes at the cost of reduced flexibility. Due to Gitlab CI's variable expansion rules, we can no longer override the image or tag of a specific implementation using CI variables.

Additionally, this moves the existing pipeline to a file in gitlab-pipelines/ and adds a second pipeline that tests against a single Lisp implementation and opens an issue if the pipeline fails. The master gitlab-ci.yml now decides which of the pipelines to run (if any) based on the trigger conditions and triggers them as children pipelines.

The cl-docker-images project will trigger pipelines whenever a new RC version is published (e.g., this will happen nightly during SBCL's freeze) and whenever a new version is released. For example, this cl-docker-images pipeline triggered this asdf pipeline.

If a job triggered by cl-docker-images fails, the ASDF Issue Bot user will create an issue so that failures aren't silently lost anywhere. I created a new user because the only real way to create an issue as part of a pipeline is via a user's Personal Access Token (PAT). The permission scopes on Gitlab PATs are too broad for my tastes, so I don't want to expose my PAT nor ask anyone else to do it. The PAT has been placed as a protected CI var in ASDF's settings (Settings -> CI/CD -> Variables).

Closes #66 (closed)

Edited by Eric Timmons

Merge request reports