On Aug 21, Otto Kekäläinen <o...@debian.org> wrote: > I would very much like to see all top-150 packages run Salsa CI at > least once before being uploaded to unstable. What people think is a > reasonable way to proceed to reach this goal? Advertise widely and frequently that there is a pool of people which is happy to help investigating the failed CI jobs. Then start personally advocating the benefits of CI to the maintainers of these packages: I expect that in most cases you will find out that they are not using CI just because they are not well informed about it.
Recently I enabled CI for most of my packages, and the experience has been generally positive. The most important benefit for me is that I can know before an upload if the packages's own autopkgtests will fail, and I also learnt about blhc. I am even considering mirroring on Salsa my few Github repositories just to get CI support. Of course, this works best if a package *HAS* autopkgtests, so it would be great if more people contributed non-trivial tests to the packages they care about. Something that many developers are probably not aware of is that they can enable CI for a repository with no code changes at all and with a single command: salsa update_projects $NAMESPACE/$PROJECT \ --jobs yes --ci-config-path recipes/debian.yml@salsa-ci-team/pipeline (salsa(1) is part of devscripts) And then they can immediately schedule a new pipeline without having to push a new commit: https://salsa.debian.org/$NAMESPACE/$PROJECT/-/pipelines/new This allows to see how Salsa CI works with very low friction and no committment at all: worst case it can be disabled again and nobody will notice. :-) -- ciao, Marco
signature.asc
Description: PGP signature
