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.
Kevin Kofler
_______________________________________________
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
