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.
