On Wed, Mar 28, 2018 at 09:09:09PM +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Mar 09, 2018 at 10:20:12AM +0100, Pierre-Yves Chibon wrote: > > On Thu, Mar 08, 2018 at 01:00:32PM -0500, Randy Barlow wrote: > > > I would like to kick off a general discussion about how we might gate > > > packages in Rawhide. I think it would be nice to get something in place > > > for the Fedora 29 timeframe. > > > > I was waiting to have some more time to work on it to kick off that discussion. > > This is cool as it means there are more people interested in having this :) > > > > > As one of the Bodhi contributors, I am inclined to suggest that we could > > > use Bodhi on Rawhide, similar to how we use it for our stable/branched > > > releases, with more relaxed rules (perhaps 1 day in testing or something > > > simple). > > > > > > It may be possible to automate the process a bit to make it less heavy > > > for developers, though there is some complication for multi-package > > > updates (more on that in a bit). For simple package updates, we may be > > > able to detect new commits on dist-git, and react to those by > > > automatically starting a Koji build, and automatically filing a Bodhi > > > update when that build is complete. I think that would be pretty nice, > > > and pingou created a PoC[0] to do this about a year ago. > > > > > > Multi-package updates won't be so easy though. It's not uncommon for us > > > to need to update packages together, and the above workflow would be > > > problematic since it would result in updates with single packages in > > > them rather than updates with multiple packages. Of course, buildroot > > > overrides would be a problem too, since multi-package updates often > > > depend on each other at build time too. > > > > > > We could create some way for packagers to indicate that a commit (or > > > possibly even a whole repo) is not intended to be "autobuilt/updated". > > > If the packager indicates this then their builds would go into a > > > rawhide-pending (similar to what we do for f27 today). Once they have > > > all their builds (and buildroot overrides) the way they want them, they > > > can create the update. > > > > > > Another idea that was tossed around in some chats I had with people > > > about this involved a system for packagers to use to create Koji side > > > tags. Bodhi manages BuildRoot Overrides today (with expirations), so > > > perhaps Bodhi could be expanded to also manage Koji side tags (also with > > > expirations). I can't remember all the details about this approach or > > > why it was suggested over the former approach, but I wanted to list it > > > to invite others to chew on it and see if it could work. > > > > > > If you have other suggestions on how we might gate packages in Rawhide > > > that are wildly different than the above, please feel free to share! > > > > I had a different idea in mind, basically try to keep the experience as close as > > what it is now. > > for single package: > > - packager commit > > - packager build > > - build is tagged into a specfic koji tag > > - test are run on this tag > > -> results go to src.fp.o > > - if tests pass > > - package is moved to another koji tag > > - package is signed > > - package is pushed to rawhide > > - if tests do not pass > > - do nothing > > - if the user submits a waiver > > - move the package to the next koji tag for signing it > > If a packager does not want to run the tests, we could have a fedpkg build > > --noci that would directly build the package in the koji tag used for signing > > the package (useful for mass-rebuild for example) > In the graphs, the red arrows are always full, i.e. signify manual steps. > Is this an oversight, or are so many manual steps actually needed in that > workflow? The one between fedpkg build --noci and koji build should be dashed indeed, the others are plain as they should I believe. > > for multi-package: > > - packager requests a new side-tag (I'd propose via bodhi) > > - packager build all the different packages in that side-tag > > - packager asks for the side tag to be merged > > - tests are run on all these packages > Are those tests run will all the packages in the side-tag, or with > each package separately installed onto current rawhide? I assume the > first, but please clarify that. They should run with all the packages in the side-tag I think. > > -> results go to src.fp.o > > --> We probably want to also report them on the bodhi request to merge the > > tag as otherwise the packager will have to go through all the package to > > find the one(s) that failed > > - if tests pass > > -> cf above > > I see two advantages of the workflow with bodhi: > - we can reuse existing reporting interfaces, for tests results, but also > for user comments. In particular I expect that the integration of bodhi > with greenwave and gating CI will keep changing and increasing, as required > by updates for stable releases, and this would have to be duplicated > in pagure, if bodhi is not used. Such features don't seem to be > applicable to upstream pagure, but mostly to the src.fp.o, and it'll > be an ongoing burden. Pagure already support reporting CI results (both on commits and on PRs) and in the workflow without bodhi, the gating wouldn't be done in pagure itself so less burden there. > - using bodhi updates gives some additional flexibility, for example we > (in the future) could make the "push bodhi updates" step *non*-automatic, > so that for example a positive karma from another maintainer would be > required. This could be used for example as "send mail to fedora-devel, > ask for checking update FEDORA-1223345464" on especially tricky or big > changes. This should be doable, though it will need a community decision for this. At first, I don't think we should allow karma on rawhide's packages, just rely on automated tests. But yes, using bodhi would allow for such a workflow if we one day desire it. > All in all, the simpler workflow looks attractive as first blush, but > I wouldn't discard the more complicated option just yet. If all the > steps were automated, the fact that bodhi is involved would not cause > additional work to the maintainer. Agreed on both accounts. Pierre _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
