Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> writes: > Matthew Miller wrote: >> Yeah, honestly, this is also a pretty serious hardship for the long tail >> of people maintaining a handful of infrequently updated packages. I'm >> hugely in favor of not checking in work in progress on the main or release >> branches, but let's not make more steps. > > I still think that the best way to do CI would be what I already suggested > at least once: > 1. maintainer pushes the commit to the branch "rawhide" or "fn" > 2. a quick synchronous commit hook validates obvious things such as the > presence of source files and patches > If this fails, the push fails and we stop here. Otherwise: > 3. another commit hook asynchronously triggers a CI build > 4. the push succeeds (without waiting for the CI build to complete) > 5. the asynchronous CI attempts to build the package > 6. if the CI build fails, the branch "rawhide" or "fn" is automatically > force-pushed back to the last commit that successfully built, and an > e-mail notification is sent. Force-pushing is safe in that case because > there was by definition no successful build, hence nothing that shipped > in any repos. Rewinding to the last successful build should work even if > multiple broken commits by multiple maintainers have been pushed since. > 7. by default, CI builds are treated as scratch builds, but in order to > conserve resources, it should be possible for the maintainer to mark a CI > build as a production build either during the build or within a > reasonable time after completion. Ideally, fedpkg build should > automatically do that instead of triggering another, redundant build if > it finds a suitable CI build to retain. > > If fully implemented (including the "ideally" part), this achieves the goal > that maintainers need not adjust their workflow at all. They just push their > changes and run "fedpkg build", the CI happens behind the scenes, "fedpkg > build" automatically sets the CI flag to retain the build if successful, and > watches the CI build unless --nowait is used. And if the build fails, they > can just commit a fix locally and redo a new push, which will also push the > previous failed commit back (but the CI will not attempt to build it again > because there is now a newer commit on top which will be built instead – and > if that, too, fails, the CI will rewind the whole thing). > > At the same time, broken commits never persist in dist-git once they are > known not to build, the history remains clean (because everything broken > gets force-pushed out of the way), and, thanks to the automatic force-pushed > rewind, maintainers can, if they wish, opt to push an amended commit (clean > history!) instead of the "the last commit was broken, fix it" commit they > have to do now (but they can still do the latter if they wish, as explained > above). In contrast, any kind of pull-request workflow, even an automatic > one, makes the history even less clean than it is now. I really like this idea! I'm afraid it's going to be pretty hard to pull off, especially the promotion of scratch builds to real builds and the force push that reverts to the latest working commit (also, that one might not work anymore at this point…), but still a goal worth pursuing. Cheers, Dan
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
