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. On the other hand, I think that 1) daily is too frequent and that 2) if there is nobody available to fix failures, any frequency is too high. So I think a reasonable compromise would be to decrease the frequency to monthly of the ones that are passing, and disable the scheduling entirely for the ones who constantly fail.
signature.asc
Description: PGP signature
