[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: salsa ci pipelines that run on schedule



Hi,

Em 2 de dez. de 2024, à(s) 17:53, Antonio Terceiro <terceiro@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.

Reply to: