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. 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. > 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? > --> 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? Or in this scenario are you suggesting that a Bodhi update has been created? The update would be less friction since we already have code to display test results on Bodhi updates. > The idea to automatically build upon commit is neat and something we can look > into, but I think it can be approached separately from gating rawhide, one > doesn't require the other. > Speaking of both changes in one go might confuse things a little. True, it's orthogonal.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
