Hi Chris, ... > >>If you or others have CI enabled on projects where you can't fix the > >>repo so CI passes and git HEAD gets green, please scale down testing > >>scope until it passes, or disable the CI. > > > >That's all nice, but when the CI config changes after setting it up > >and then breaks, we can't expect everybody to run around busily and > >disable newly failing or even newly appearing jobs. > > https://salsa.debian.org/debian/shadow/-/pipelines/1178928 > > | Unable to run pipeline > | jobs:extract-source:script config should be a string or a nested array of > strings up to 10 levels deep > > I don't know what that means or why it happens. Maybe including yaml > files is just a bad idea? If there was some change src:shadow should > have followed, were there bugs filed about that change that I've > missed?
Last time the CI in shadow passed was in August 2025 [1]. It started failing in September 2025 [2]. You should have at that point investigated and updated the gitlab-ci.yml in that project instead of letting it fail for over a year. Now the CI in that project is running in vain and not catching any regressions that might have happened in between. The point of my email was to recommend that if you don't maintain the CI and try to fix it, you (and all of Salsa) is better off it you just remove that gitlab-ci.yml file from the project. No CI is better than a failing CI. Maybe some other day somebody who wants to contribute to shadow adds back a salsa-ci.yml with a working configuration. Who knows, perhaps even the vanilla config without any custom stuff might work for this package (I didn't try). > I notice the pipeline for > https://salsa.debian.org/salsa-ci-team/pipeline/-/commits/master?ref_type=HEADS > is also red, incl. on Otto's commit > 964d824a0bcf63c2a12a562aa57e9825534f3b16 from a month ago. You are trying to imply that Salsa CI maintainers themselves are ignoring failing CI and thus you can do it too. However, the CI is actively maintained and we do turn off features and pipelines if it is deemed that Debian/Ubuntu is too broken to run them. Thus we live up to the principle that it is better to turn off CI if it can't be fixed and can't be green, than to pollute the CI landscape with failing red tests. That commit referenced above was green when merged a month ago [3]. A later re-run started to fail because the GitLab CI runners Salsa uses cannot connect to the apt repositories of Ubuntu Resolute anymore (nor Stonking). This is a permanent infra problem no Salsa CI maintainer can do anything about and thus we have decided to disable it [4]. For most of September the CI failure on Salsa CI's own regression testing pipeline has been caused by Bullseye release being broken on security.debian.org [5] which we are solving by stopping use of security.debian.org and use snapshots.d.o instead as a workaround[6]. Please try to keep your own pipelines green. If there are external reasons that it is impossible to keep it green, then scale down the scope of the tests jobs or as a last resort turn off CI completely. Having failing CI for a year like in 'shadow' does not help catch any regressions, and only wastes resources for others who do want to run CI and who do look at results and address issues when CI flips from green to red. [1] https://salsa.debian.org/debian/shadow/-/pipelines/921781 [2] https://salsa.debian.org/debian/shadow/-/pipelines/938780 [3] https://salsa.debian.org/salsa-ci-team/pipeline/-/pipelines/1143521 [4] https://salsa.debian.org/salsa-ci-team/autopkgtest-lxc/-/commit/7fa2730035386a4be931bc1193a5f481c1c05852 [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1147093 [6] https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/758
