Re: management of debian/salsa-ci.yml (Was: Why is the team standard to use two-file includes for Salsa CI?)
On 15/08/25 at 20:47 +0200, Lucas Nussbaum wrote:
> On 15/08/25 at 12:28 -0300, Antonio Terceiro wrote:
> > On Fri, Aug 15, 2025 at 08:11:08AM +0200, Lucas Nussbaum wrote:
> > > 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?
> >
> > This probably makes sense. Do you known how many of the team packages that have
> > anythine extra in there? From the ones I have cloned locally, at least
> > these have:
> >
> > gem2deb
> > itamae
> > rake
> > redmine
> > ruby-build
> > ruby
> > ruby-selenium-webdriver
> > ruby-specinfra
> > ruby-unicode-plot
>
> Yes, see the JSON dump below.
>
> In short, probably less than 100 packages with custom stuff, mostly
> configuration variables, including some custom configuration that would
> be worth re-checking.
>
> It would be easy to preserve the custom stuff while implementing a
> transition from the current includes to a team-specific one.
I tried the team-specific include in ruby-peach, and it works.
Lucas
Reply to: