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:

To Enable

  1. Set Settings > CI/CD > General pipelines > CI/CD configuration file

    • debian/salsa-ci.yml
  2. ensure that debian/salsa-ci.yml exists in any branch where you want CI to run

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

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?

  1. branch2repo is an add-on to, which also uses debian/salsa-ci.yml

  2. having the file under debian/ is more in line with the Debian habit of keeping our config separate

  3. 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.

  4. 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.