Before enabling CI
If you wish to enable Continuous Integration (CI) on a repository that is part of the Installer-Team's namespace, it probably has IRC notifications setup, in which case you need to make sure that they're not going to be sent for every little action a job might perform (because that's a _lot_ of things), so check the following -- look in the *CI/Webhooks* settings and ensure that:
- the KGB webhook URL is set to something like
in particular, the pipeline_only_status= settings are there to limit the plethora of messages that would otherwise be sent.
Jobs events is unselected
Set Settings > CI/CD > General pipelines > CI/CD configuration file
ensure that debian/salsa-ci.yml exists in any branch where you want CI to run
see https://salsa.debian.org/installer-team/branch2repo The minimal content is:
--- include: - https://salsa.debian.org/installer-team/branch2repo/raw/main/trigger_b2r.yml
Although, if you're really just setting the minimal content, you should instead simply set the CI/CD configuration file setting to be:
and then there's no need to create a salsa-ci.yml file.
What's all this then
In salsa repos. where the above has been done, every push will result in the package being built. It will also (either automatically, or after a user clicking a play button) create a mini-iso which should allow the UDEB to be tested, and should also offer the chance to atest that mini-iso automatically on https://openqa.debian.net/
What do I need to do to be able to stick my fork into all that CI goodness?
When you fork a repository with the CI/CD configuration file set to a non-default value, sadly (at the time of writing) gitlab does not carry that setting over to the new repository, so one has to apply the same setting to the new repository by hand to get CI to work in the new fork.
If the debian/salsa-ci.yml exists in the repo. you're forking, all that should be needed is setting debian/salsa-ci.yml as in step 1. of #To_Enable
why not use .gtilab.yml?
branch2repo is an add-on to https://salsa.debian.org/salsa-ci-team/pipeline/, which also uses debian/salsa-ci.yml
having the file under debian/ is more in line with the Debian habit of keeping our config separate
for packages with an upstream, if they also uses gitlab, the may well already have a .gitlab.yml which is pretty likely to do something useless or unhelpful on Salsa.
- if downstream distros want to use gitlab, or if Debian folk want to setup their own gitlab instances with differing configurations, they might not want our CI configuration running in an environment where it doesn't work.