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
