Hi,
i think the barrier is likely to be "i didnt know you could do that?" >> >> rather than "how do i use that?"
Salsa CI is and has always been opt-in.
oops - i meant the oppposite, ie make people have to opt out of having
it run, rather than have to enable it
A human needs to verify that the pipeline passes when it is activated,
fix disable it or fix things if the CI isn't green. It does not make
sense to activate it unattended, as it would risk causing a lot of
failing pipelines and useless noise and a culture where people loose respect for "pipeline greenness".
I dont really understand this point -- is it based on some empirical evidence?
Yes, I don't have any hard evidence to back up a claim about culture
or "respect for greenness", but I hold this view strongly based on
experiences on working in software development both as an engineer and
manager in several very large projects and operations, and
unfortunately have witnessed more than once CI systems loosing their
usefulness and becoming time sinks after respect eroded and people got
used to failing pipelines. I also have the opposite experience from projects/businesses that did value pipeline greenness highly, and saw
how much less bugs they had and how much faster any new regressions
were fixed in an environment where greenness was respected.
my opinion is that
- other than the first "enabling", every pipeline runs unattended
- people are not going to gain any "respect" for "pipeline greenness" by hiding the pipeline
- commits that fail the pipeline are still bad if the pipeline didnt run, so why hide that information?
- if you want people to "respect the pipeline" you want more noise on such bad commits, not less?
CI is a feedback system. Having unattained runs that fail for a long
time is worse than having a situation where a person starts working on
a project, realizes there is no CI, and then activates it before doing
other changes, and potentially uses the feedback to fix some initial
issues or scope down the CI to exclude failures that are unreasonable
for them to fix. If you start off with a CI that has been failing for
a long time, you are kind of forced to do a lot of detective work
regarding the pipeline to check why it was failing yesterday, a month
ago and a year ago and then piece together what the sources of the
regressions were and how to fix it. It is mentally also much harder to
decrease the scope of what testing the CI did if somebody else enabled
it in full earlier, as you need quite a lot of evidence to have the
confidence to disable some jobs. If you are the person activating the
CI in the first place, you will be much faster in fixing it and have
better confidence in doing the right engineering decisions to make it
green.
Also, enabling Salsa CI is very easy: just put commit the template debian/salsa-ci.yml on a dev branch and push. If it works right away
you can then just merge that commit on debian/latest, and you are
done. The actual time consuming part if fixing the detected failures,
and that is not accelerated by enabling Salsa CI Debian-wide - in fact
the work of getting a CI green is more likely slowed down if the
person who enabled it and the person who is responsible for fixing it
are different people.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)