Thoughs on adding CI jobs on all the Python Team's repositories ?

For now the answer is: don't. Please see the discussion on debian-devel on it.

Thanks for pointing that thread to me, I don't have the bandwidth to follow -devel :)

I'll relay that back to the python list. I still intend to work on a draft to modify our packaging policy to include the use of Salsa CI, but I'll wait for you to work out the current quirks and give us the all clear to propose it officially.

Thanks for your time.

NB: FTR, here's the thread in question:

And if you go forward with this, you should make sure to not run all the pipelines at once when you do the migration. You can follow those instructions to avoid the pipeline on push: https://salsa.debian.org/salsa-ci-team/pipeline/#skipping-the-whole-pipeline-on-push

Then the pipeline will run for subsequent pushes which will not happen all at once.

Yes, that's why I mentioned we'd use git push -o ci.skip :)

mentioned in merge request python-team/tools/python-modules!12

Dear Salsa Admins,

We had a similar discussion in the Debian Med team about enabling CI for all of the team's repositories. I'm wondering what the situation is now regarding the possibility of enabling CI team-wide. Thanks in advance and thank you for the excellent service!

mentioned in issue #291 (closed)

Hi @pollo and @rbalint - Does the Python team and Med team now have Salsa CI enabled team-wide? Can this issue be closed?

You might also be interested to know that some of us are working on a proposal to get as many maintainers as possible to run Salsa CI at least once prior to every upload to ensure that the official Debian repositories have minimal amount of regressed packages at any given time. See dep-team/deps!8 (closed) and +1 if you think the proposal makes sense.

Hi @otto,

Thanks for raising this. This is the discussion I referred to where the Med team was already open to enable CI team-wide but we were waiting for green light from Salsa admins which I haven't seen given: https://lists.debian.org/debian-med/2020/11/msg00071.html

A follow-up email from @tille which I haven't seen answered publicly: https://lists.debian.org/debian-med/2021/02/msg00166.html

I think CI is still not enabled team-wide for the Med Team's packages despite our desire to do so. I was not active recently, thus I may have missed improvements in this area.

It is correct that we manually set Salsa CI for every single new package. I admit this is a nuisance and given the fact that we end up with Salsa CI for every team package anyway it does not matter whether it is set manually or if it would be set automatically - the result from a resource consuming view is the same. Its just burning a tiny fraction of developer time. My guess is that this could be set easily on Salsa but nobody has asked with sufficient effort for it. I was asking Salsa CI (and its actually Salsa CI which needs to provide the resources) admins last year at DebConf23 and they are fine.

For the Python Team, I'd say there's currently no push to make this a policy item. Considering how slow Salsa CI currently is, I'd say this issue can be closed for now until things change.

If you ask me (wearing my DPT member hat) I would really welcome Salsa CI as default. I'm setting it for any package I'm touching. The argument that Salsa CI is slow might hopefully become void (wearing my DPL hat I'm working together with the admins) and finally even a slow QA check is better than no QA check where issues might slip trough.

from our point of view: just go ahead. I will also revamp parts of the runner setup soon which should improve the overall performance.

closed

In the README at https://salsa.debian.org/salsa-ci-team/pipeline we say:

It is recommended to set this value to debian/salsa-ci.yml and create the file containing at least the following lines:
---
include:
  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml

If the setting debian/salsa-ci.yml is made the default globally for salsa.debian.org or just the team salsa.debian.org/debian/ it would save people from doing one step of setup. This is a small step though, the biggest work is always checking that the pipeline is green and making it green if it wasn't fully passing on the first run.

I think this recommendation is not optimal. IMO recipes/debian.yml@salsa-ci-team/pipeline would be the best recommendation and/or default for projects and only customized pipelines should use debian/salsa-ci.yml with the desired custom settings. That would require the least amount of work from maintainers.

While it decreases the work of activating the pipeline initially, it increases the work of fixing pipelines and preventing wide-scale proliferation of failing pipelines.

In worst case it may end up in a situation with so many failing and unmaintained CI pipelines that people lose respect for having a green CI, and then a lot of value is lost that could otherwise be gained from a culture where people keep an eye on CI and keep regressions out but treating every red pipeline as an anomaly that needs urgent fixing.

Even when the pipeline is passing, the setting and what pipeline it refers to is not visible to contributors which leads to confusion when people make changes that cause regressions and they need to investigate them.

I think it is better to optimize that keeping pipelines green is easy and we have a culture where having consistently green pipelines is the expectation and not just an occasional add-on.

Thoughs on adding CI jobs on all the Python Team's repositories ?

Child items ...

Activity