On Fri, Jul 03, 2020 at 11:11:30AM +0200, Nicolas Mailhot via devel wrote: > Le vendredi 03 juillet 2020 à 09:48 +0200, Pierre-Yves Chibon a écrit : > > On Thu, Jul 02, 2020 at 12:10:58PM +0200, Björn Persson wrote: > > > Nicolas Mailhot wrote: > > > > The same process that commits a new state of the changelog file > > > > in > > > > sources, > > > > commits the date that was written in the changelog in a separate > > > > key = > > > > value > > > > file (with the components of the build evr, the last packager id, > > > > etc). > > > > > > Do you mean that the key/value file will be committed to Git from > > > inside > > > Koji? Do the Koji builders have write access to Git? > > > > This is the part that worries me a little about this approach. > > Builders currently do not have commit access to git and I'm not sure > > if we want them to considering they have git installed (so they can > > clone) as well as access to all the packages in dist-git from a > > networking point of view (again so they can clone). > > So if we were to give the builders commit access to dist-git, an > > attacker could easily commit to any other packages, potentially from > > something as easy as a scratch-build. > > From a purely architecture POW I’m convinced the proposed approach is > the correct approach. Anything else proposed so far involves: > – tying a low-level event like "build occurred at date XXX" to high- > level Fedora infra (making our workflow non portable and > incompatible with downstreams and third parties) I don't think this point is true in the case of rpmautospec. > – taking bets in git that a build will occur and succeed (before it > actually occurs and succeeds, in real life builds fail for various > reasons), and I don't think this point is true, in the case of rpmautospec where the tagging is done by the build system, once that build has succeeded. > – attempting to munge spec file behind the packager back (unlikely to > work fine the more automated and dynamic we made those). I'd contest the "behind the packager back" in the case of rpmautospec considering this is well documented, but I fear that qualification may just have been a little trolling :) > However, because it’s the correct architecture solution, it also forces > to make hard architectural choices, instead of mixing unrelated things > in git and pretending that makes the result fine. Mixing unrelated > things in a pile of container or git poo and pretending the result is > fine is exactly what I hate in contenerish build workflows and why I > work on rpm packaging. > > From a pure high-level view, the thing in our infra that gates builds > and decides whether they are official or scratched is bodhi. > > So if you want to push Fedora release logic to its ultimate conclusion, > the thing that should be in charge of committing the new > release/changelog build state to package history in git is bodhi, not > koji. And you can put security related checks there, since deciding to > push things to users requires security related checks anyway (that > probably also involves branching while a bodhi update is in flight and > not approved yet). > > However, that’s if you want to push the model to its ultimate > conclusion and have something nice solid, automated, and future-proof. > > If you don’t want to touch bodhi, and it you do not want koji to commit > to git (which, is not the best of things for the reasons you stated, > and for the reasons I stated), you can just: > – make the koji client return the URL that will contain the SRPM at the > end of the build process if it succeeds. > – have the person of script that called the koji client (and has, > presumably, write access to the corresponding packages) consult the > build results later > – and have this person or script decide if he or it wants to commit the > build result to history or not So if I understand correctly the proposed workflow is: - git commit your changes && git push - fedpkg build the commit - if build succeeded: (the build system if we manage to, or the packager:) - $editor release_file - adjust the release value in that file - git add release_file && git commit && git push The suggestion I'm proposing would be: - git commit your changes && git push - fedpkg build the commit - if build succeeded: - the build system tags the commit built with the release value And we could trivially re-use the koji plugin that was written for rpmautospec to do this, in whichever format your macros need. This lowers the amount of manual interventions and reduces the risk of conflict as the release_file would change for every build (conflicts which would also appear when doing git merge and potentially in PRs, especially if that file remains manually updated). Basically, we are introducing another "sources" file that will conflict for every release change rather than version change. Also, if you have long running builds (say chromium or libreoffice that takes multiple hours). If the commit updating the release_file happens at the end of the build, there could have been another commit push while the build was happening. Say we're building commit B and updating the release_file in B', we would end up with a git commit log looking like: A -> B -> C -> B' But "C" wasn't build in the release that B' indicates, so the git history becomes quite unreliable to link it to a build. In addition, if the commit (B') happens in the build system, the push is likely going to fail as there is a new commit in the repo (or we pull first, but then we come back to the issue described above). All this to say that I do not understand why tying so much this idea to a file in git vs a git tag. The git tags could contain the same information as the file, it would just be stored in a different place but it would still be in git. The action to add a git tag could be restricted to the build system, thus reducing the risk of messing up the information used by your macros. The tags will not conflict on PRs or git merge, they can be made after the build without re-writing history or mis-representing it and as such they allow to keep the mapping consistent between what is in git and what was built in the build system. Does that make sense or am I missing something here? Pierre _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-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/packaging@xxxxxxxxxxxxxxxxxxxxxxx
