[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

management of debian/salsa-ci.yml (Was: Why is the team standard to use two-file includes for Salsa CI?)



Hi Soren, all,

On 14/08/25 at 11:01 -0700, Soren Stoutner wrote:
> Lucas,
> 
> Why is the team standard to use two-file includes for Salsa CI?
> 
> https://salsa.debian.org/ruby-team/redmine/-/commit/
> d0af6274cf5cb42deb13a536ee0802fb64b01172

For context: I made this change as part of an effort to uniformize the
way our packages are maintained in salsa. See
https://lists.debian.org/debian-ruby/2025/08/msg00003.html

There was a few packages (< 10 out of 1246) using the single-file
include, so I modified them to use what is used by other packages in the
team.

> That was the previous official recommendation for Salsa CI, but it has been 
> changed to a one-file include:
> 
> https://salsa.debian.org/salsa-ci-team/pipeline#salsa-continuous-integration-ci--quality-assurance-for-debian-packaging

Right. I saw that as a two-step process: first uniformize our
packaging standards as much as possible, then discuss possible changes
from there.

In the email mentioned above, I wrote:
> 5/ discuss whether we should change the way we configure CI. I wonder if
> it would make sense to have a team-specific include, that would itself
> include the salsa-ci's team ones. That would allow for centrally
> changing some stuff.

I wonder if the should centralize CI configuration, using something
like:
------------------------>8
---
include:
  - https://salsa.debian.org/ruby-team/meta//raw/master/salsa-ci.yml
------------------------>8

This would allow us to use defaults that differ from salsa-ci-team's
(centrally enable a job that is disabled by default) or add a custom,
team-specific job. What do you think?

Lucas


Reply to: