Re: management of debian/salsa-ci.yml (Was: Why is the team standard to use two-file includes for Salsa CI?)
On 16/08/25 at 09:57 -0700, Soren Stoutner wrote:
> On Friday, August 15, 2025 10:08:09 PM Mountain Standard Time Lucas Nussbaum
> wrote:
> > On 15/08/25 at 15:11 -0700, Soren Stoutner wrote:
> > > On Thursday, August 14, 2025 11:11:08 PM Mountain Standard Time Lucas
> > > Nussbaum>
> > > wrote:
> > > > 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?
> > >
> > > I would be fine with that. However, up until the point that we have an
> > > accepted, centralized Ruby Team CI configuration, I think we should follow
> > > the default recommended Salsa CI configuration unless there is a good
> > > reason to make modifications. As such, I would recommend reverting this
> > > commit:
> > >
> > > https://salsa.debian.org/ruby-team/redmine/-/commit/
> > > d0af6274cf5cb42deb13a536ee0802fb64b01172
> >
> > Hi Soren,
> >
> > To make sure we are on the same page:
> > Do you agree that this would not result in any change in the way the
> > package is tested, given the content of
> > https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/
> debian.yml
> > ? And that it would only result in making redmine a special case again
> > among Ruby packages, since it would be the only one with that CI config?
>
> 1. Yes, I agree that these are functionally the same, at least for now.
> However, at some point in the future, the one-line include might diverge from
> the two-line include in terms of what it performs.
>
> 2. Point number 1 is part of the reason why I feel strongly that these
> commits should not have been made in the first place.
>
> 3. The two-line include salsa-ci.yml was a previous Salsa CI recommended
> default. This is one of those cases where a bunch of packages were following
> a previous standard, many of the package maintainers didn’t notice that the
> standard had changed, some of the package maintainers did notice and updated
> their packages. In this case, I think it would be best to convert all of the
> Ruby packages to the new standard, rather than downgrading those which have
> been updated to the now-deprecated standard.
>
> 4. Because there is discussion about perhaps creating a team Salsa CI
> default, I can see some wisdom in holding off on converting all salsa-ci.yml
> to a one-line include as long as the new Ruby Salsa CI is going to be
> developed fairly soon. Otherwise, I would be in favor of converting all of
> Ruby’s default two-line includes to one-line includes now.
>
> 5. At a minimum I would recommend you revert all of your commits that changed
> the current standard one-line includes to the deprecated two-line includes. I
> haven’t taken the time to find them all yet, but I would appreciate you
> reverting the one I lined to above as well as this one below. Or, I can do it
> the next time I make an upload.
>
> https://salsa.debian.org/ruby-team/ruby-with-advisory-lock/-/commit/
> 71631a06e02c1396ac1ae86f1303c7078f8f2065
I would agree with you that it would have been better to move the
remaining packages from the previous standard to the new standard if a
large number of packages were already following the new standard.
In that case, it was more like:
- about 1200 packages following the previous standard
- about 10 packages following the new standard
So in that case, it was easier, as a first step, to move the 10 packages
back to the previous standard and thus reduce heterogeneity among
packaging practices and identify other kinds of outliers. I plan to work
on moving to a team salsa-ci include, or to the recommended practice,
after this first step.
I did not keep track of the packages where I made those changes, so I
cannot easily revert them all, but if you care strongly about that, feel
free to revert packages whether it matters to you to new standard in
your next upload (unless the move to a team-standard practice is
finished by then, which would remove the need for such a change).
Lucas
Reply to: