Hi, > Em 2 de dez. de 2024, à(s) 17:53, Antonio Terceiro <terce...@debian.org> > escreveu: > > On Sun, Dec 01, 2024 at 02:45:36PM +0530, Ananthu C V wrote: >> Hello, >> >> I write this mail to ponder about something that has been bugging me since >> a long time now. If any of you follow the #debian-ruby-changes irc channel, >> you'd have noticed the recurring ci results of a few select packages. At >> first I thought this to be the maintainer actively working on them, but later >> after some time after checking found out that the package I checked hasn't >> actually been touched in 4+ years. And recently I tried to investigate what >> is triggering the perpetual ci runs and found out that they all have pipeline >> schedule enabled to repeat the ci every day, with a cron job of `0 4 * * *`. >> >> The packages I have noticed that have this behaviour are: >> - nadoka >> - ruby-sigdump >> - ruby-rspec-instafail >> - ruby-childprocess >> - ruby-flexmock >> - ruby-parallel-tests >> - ruby-serverengine (0 7 * * *) >> - ruby-strptime >> - ruby-i18n (0 4 * * 5) >> - ruby-crack (0 11 * * 4) >> - ruby-spoon (0 1 * * 4) >> - ruby-cool.io (0 9 * * 0) >> >> Among these packages, most were last uploaded in 2020 or 2021 and one or two >> in 2022. ruby-childprocess was last uploaded in 2023 and only ruby-i18n and >> ruby-cool.io are in the list of 2024 uploads. Also ruby-serverengine pipeline >> fails every single time. >> >> As such, is this a good use of the ci resources? I don't think there is much >> merit in keeping such hightly frequent pipeline schedules (specifically given >> they aren't under active development or break regularly). And personally, >> because I sometimes go through #debian-ruby-changes, I find this cluttering >> the info there. So I would like to ask the team what to do regarding them. >> Currently I see three options: >> >> a) leave them as is without changes >> b) reduce the cron job frequency - to maybe monthly or once in three months >> or so >> c) drop the schedules pipelines > > A periodic run has the advantage of "refreshing" the system against > which the CI pipeline runs. e.g. a package can have a passing pipeline > today, but in a few weeks a change in sid might make the package fail.
I understand what you said but in this case we would have Debci blocking the migration to testing, which will avoid any issue to our users anyway. The maintainer/uploader of the package causing the issue will notice at some point (hopefully) and sort it out in some way. If we think this approach is the best, we would need to schedule the ci pipeline of all packages we maintain instead of just a small set of packages, which would use too much resources from salsa-ci. Lucas Kanashiro.
