search

fedora-infra / koschei

Continuous integration for Fedora packages
GNU General Public License v2.0
37 stars 15 forks source link

[RFE] Bulk-editing packages #128

Open voxik opened 7 years ago

voxik commented 7 years ago

Updates of Ruby on Rails takes some time and during this period, there is high chance that Koschei will notice that something is broken. This produces too much noise, since it is expected that during the rebuild, the dependencies are broken. Would it be possible to temporary suspend Koschei (with some default expiration period) for some (group of) packages?

mizdebsk commented 7 years ago

You can achieve this by setting "manual priority" to negative value (which is documented at https://fedoraproject.org/wiki/Koschei#Priorities). Eventually accumulated dynamic priority (which depends on several factors, including time and number of build-dependency changes) will outweigh negative manual priority and package will be rebuilt. Setting manual priority is a one-time thing - once package is rebuilt, manual priority is reset to zero.

voxik commented 7 years ago

Interesting idea. But this solves just part of the issue. How to set up the priority for group of the packages? E.g. I know that the last package in the set I'm going to rebuild is rubygem-rails, but I'd like to setup the negative priorities for every of its BR.

voxik commented 7 years ago

Actually it is not just about BR ... but also every package which depends on rubyem-rails is broken during the rebuild ...

mizdebsk commented 7 years ago

Currently you can set package priority only in web UI, one-by-one. Would CLI tool be useful?

Actually it is not just about BR ... but also every package which depends on rubyem-rails is broken during the rebuild ...

And technically speaking, Koschei would be correct to say that these packages are broken, temporarily. I can't think of any good solution here.

(Initially I considered letting people mark packages as "known to be broken", or in other words, "assign" failures to themselves. That would prevent spamming users with needless emails and could help a group of people to coordinate fixing packages. "known to be broken" would be cleared automatically after successful build. But in the end I didn't think this was worth implementing.)

voxik commented 7 years ago

Currently you can set package priority only in web UI, one-by-one. Would CLI tool be useful?

Web API would be probably OK ;) CLI would be probably good as well. One-by-one is very suboptimal in this context, if we could set the priority to the whole "ruby-rails" group at once, it would help a bit, but is still suboptimal ;)

And technically speaking, Koschei would be correct to say that these packages are broken, temporarily. I can't think of any good solution here.

Of course Kosechei is right, but we know about it that Koschei will notice and we don't need it, since it makes harder to spot the real issues, in case I am done with e.g. Ruby on Rails rebuild and now I'd really love to see if everything still works.

So speaking of rubygem-rails, I'd like to think about it this way:

"I am going to rebuild rubygem-rails and possibly all its BR, I know that during this period, rubygem-rails, its BR and also everything which actually R or BR rubygem-rails will be possibly broken. Please Koschei, don't check the package for 24h (and if needed, I could specify this timeout to 12h or 48h or whatever range). If I am not proceeding as expected, I'd like to be able to extend the timeout. If I am done earlier, I'd want to let Koschei know that I am already done and Koschei can proceed with its business as usually. Now lets see what Koschei will notice to be broken due to the update."

You suggested change of the priorities. Not sure how precisely is the priority computed now, but I can imagine, that instead of the timeout, the priorities set to some negative value could be option as well.

"known to be broken", or in other words, "assign" failures to themselves.

This can't work IMO, since there is no timeout. People will set some packages to be broken and they will never reset the flag etc. I perceive it as completely different topic.

mizdebsk commented 7 years ago

More generic feature would be allowing bulk-editing of any set of packages - not only manual priority, but also arch override and "skip resolution" flag. Via web or REST API (#115), with help of not-yet-existing CLI tool.