[Ruby Sprint 2020] Disabling not-so-useful jobs by default for team maintained projects in Salsa CI pipeline
Hi,
During the Ruby sprint that is currently happening in Paris, there was a
discussion regarding whether we need all the CI jobs that salsa-team's
CI config[0][1] adds in the pipeline. The concerns were essentially
focused on resource wastage on attempting jobs that doesn't make sense
to most of the packages that the team maintains.
##### Decisions taken during the sprint
1. Disable piuparts globally for all the packages.
2. Enable blhc and reprotest only for the packages that have C extensions.
3. For new packages, add logic to gem2deb to modify CI config template
used by it to run either arch:all or arch:any jobs based on the package.
For now, leave the existing packages as is.
4. Document how those who need the tests can flip it back, and give
common usecases where these jobs make sense.
##### Implementation - Proposal 1 (involves mass update of all the packages)
Note: An alternate proposal is given at the end of the mail
1. Update CI config template copied by gem2deb to include the following
snippet
```
variables:
SALSA_CI_DISABLE_BLHC: 1
SALSA_CI_DISABLE_PIUPARTS: 1
SALSA_CI_DISABLE_REPROTEST: 1
SALSA_CI_DISABLE_BUILD_PACKAGE_ALL: 1
SALSA_CI_DISABLE_BUILD_PACKAGE_ANY: 1
```
2. Update gem2deb codebase to modify the CI yaml file after copying it
to remove `SALSA_CI_DISABLE_BUILD_PACKAGE_ALL: 1` or
`SALSA_CI_DISABLE_BUILD_PACKAGE_ANY: 1` line depending on whether the
package is arch:any or arch:all so that new packages will be handled
properly.
3. Update the CI yaml file for all existing packages accordingly
(ideally, via a script, and ensure to skip CI either via commit message
or git push options so that we don't trigger ~1000+ pipelines)
4. Write documentation on wiki for how package maintainers who need to
can re-enable these tests, or link to Salsa team's documentation on the
variables.
Because the discussions were essentially only between those who
physically attended the sprint, it makes sense to announce this to the
mailing list before actually starting writing code. So, please comment
as soon as possible. If we don't end up with a different decision by
February 15th, I plan to move forward with this plan.
---
Alternate/Quickfix proposal
1. Set SALSA_CI_DISABLE_BLHC, SALSA_CI_DISABLE_PIUPARTS, and
SALSA_CI_DISABLE_REPROTEST to 1 in group variables of ruby-team group in
Salsa. This will disable the jobs for all the projects in the group.
2. For projects with C extensions, flip the change back by setting those
variables in individual project settings.
3. Update gem2deb codebase to modify the CI yml file after copying it to
append `SALSA_CI_DISABLE_BUILD_PACKAGE_ALL: 1` or
`SALSA_CI_DISABLE_BUILD_PACKAGE_ANY: 1` depending on whether the package
is arch:any or arch:all.
4. Update the CI yaml file for all existing packages (ideally, via a
script, and ensure to skip CI either via commit message or git push
options so that we don't trigger 1500 pipelines)
Obvious problems of this alternate proposal:
1. The way GitLab's precedence of variables[0] work, variables defined
in project settings has priority over group variables, which themselves
have priority over variables defined in CI yaml file. So, to enable a
job we disabled globally via group variables, people will have to use
project variables. Flipping them directly in CI yaml files will not
work. This is a visibility problem.
2. Project variables can be updated only by Maintainers or Owners of the
project, and not Developers. So, to re-enable these tests, developers
will have to ask someone with access to set the variable.
3. Setting variables in project settings or group settings have a very
limited visibility, and will not be obvious to a new person why some of
the jobs didn't run even if the CI config file has all the jobs defined.
[0] https://salsa.debian.org/salsa-ci-team/pipeline/blob/master/salsa-ci.yml
[1]
https://salsa.debian.org/salsa-ci-team/pipeline/blob/master/pipeline-jobs.yml
[2]
https://docs.gitlab.com/ee/ci/variables/#priority-of-environment-variables
---
Regards
Balu
Reply to: