On Mon, Mar 12, 2018 at 06:05:22PM -0400, Randy Barlow wrote: > On 03/09/2018 04:20 AM, Pierre-Yves Chibon wrote: > > 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) > > I would really like to have tests in src.fpo, but I think they would be > most helpfully displayed on pull requests, rather than after I've > already made a Koji build. This is more similar to the workflow I'm > accustomed to when I work on Bodhi's upstream code - I submit a PR and > CentOS CI (which is very nice btw) chews on it and tells me if I'm good > to merge. For a single package update (which is most of what I > personally do) it would be very nice to have this before I merge my PR > in Pagure. I don't think the two are antagonist, one is the pre-merge/PR workflow with the tests ran on the PR, the other is post-merge. Both approach can already be supported today. > So all that to say that I like the above, but I'd like to propose that > there also be some tests run before I commit (i.e., merge the PR) and > build in Koji (for cases where we use PRs. I'm not proposing we require > PRs, but that it be available for those of us who would like to use that > workflow). PRs do get the simplekojici build today, which is cool. I'd > really just like a few more tests than that to be run as well. We're working on the pipeline that will run the tests present on all and every package having tests (instead of the restricted set of packages included in Fedora Atomic Host). The next step will be PR testing. Feel free to poke Dominik Perpeet if you want more details :) > > 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 > > -> results go to src.fp.o > > At this point there aren't pull requests, right? Where would we display > this in src.fp.o that would make it clear which change the test results > pertain to? In the commit page itself, for example: https://src.fedoraproject.org/rpms/perl-IO-HTML/c/69a460858b8c1f47bb6320faa6f310dab6808184 (that's the fbom service: https://pagure.io/fedora-ci/fbom which flags in src.fp.o successful build made in koji, it's not currently running, we need to process the RFR: https://pagure.io/fedora-infrastructure/issue/6717 so don't look for it on every repo) > > --> 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 > > Do you mean that Bodhi would display them on a side tag page? That was my proposal yes. > Or in this scenario are you suggesting that a Bodhi update has been created? I don't really see the need for one, so in this proposal, the bodhi update mechanism wasn't used. Bodhi was used for only for managing side-tags and since merging a side-tag will be impacted by the test results including that info there made sense to me. > The update would be less friction since we already have code to display test > results on Bodhi updates. That's fair, on the other side we're going to have to build an entirely new part in bodhi and we potentially may want to present the test results differently there (don't know, something to think about). Pierre
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
