Koji would need to be extended to offer such a thing. Currently, Koji does not have any logic to resolve the submitted ref to a commit/revision and store it as dedicated metadata. We do store the DistGit URL as extra data, but if you submit to Koji directly using a ref, it doesn’t dereference it to the commit, so you can easily break things.
In order to do this properly, when a ref is submitted to Koji, it needs to be resolved and stored as a direct database entry to check against. Once it exists as a database entry, it’s easy to do what you ask for as a Koji hub policy.
I’ve reviewed @ngompa’s merge request and I think I agree that it’s a reasonable approach.
I’d also like to note one benefit to it that doesn’t seem to have been discussed here: while it is definitely most useful if the buildsystem can handle it automatically, it has value even if we never get around to it: with targeted mass rebuilds such as those for rebuilding due to a dependency change, like a soname bump.
As long as we make this value configurable in the settings for an on-demand side tag (like we do for the bootstrap field, then it becomes quite easy for a maintainer to trigger a new build in those side-tags without the need for pushing a commit to the dependent packages. Thus, they don’t need commit access to those packages, just the ability to trigger the build.
I’m strongly in favor of merging this MR, but I’d like for us to reach something approaching a consensus before I do so.
Looking at impact and risks, I think to play on the safe side we need the ability to restrict permissions in Koji for people to trigger builds without changes in dist-git. And then initially we would restrict this ability to releng or proven packagers group.
I’m curious what you think would be the impact of this that isn’t already a potential risk today. Even now, a maintainer can trigger a build of any commit that has already been built and it will proceed at least until the point at which the BuildSRPMFromSCM step concludes, at which point it knows what the NVR will be and can compare it to Koji’s existing list.
I suppose a malicious member of the packager group could try to trigger a mass-rebuild of all the packages in Fedora (and flood Rawhide with useless updates), but I feel like we’d notice that pretty quickly, revoke their privileges and cancel the builds in the queue.
Sure, but even doing it by hand creates collision problems because if it’s not automatically managed by the build system, then builds and rebuilds across different side tags will collide.
Of course it can be used this way, but it doesn’t fix many workflow problems if it’s used manually. Not to mention, it applies the same value across all builds in a side tag, when the goal is the counter is package-specific, rather than tag-specific.