Greetings everyone.
Fedora Release engineering was made aware recently that some real builds seemed to have been done from commits not in any branch in the main repository for the package. All cases we are currently aware of were maintainers mistakenly building from a forked repo with a valid pull request.
On investigation, this was found to be due to some changes in how koji does the buildSRPMFromSCM task and us being unaware of the implications of that change.
In short, when a pull request is created, pagure keeps track of those commits in refs/pulls. Previously koji did a 'git reset' to the exact commit, which would only work for commits on a branch. The new method with 'git fetch' will follow refs and find the pull request commit.
Upstream koji developers have created a plugin for us to check policy after the checkout and require official builds to be from a commit that is in a branch. This plugin has been deployed and is active.
Sorry for any confusion this issue may have caused.
kevin
_______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org 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-announce@lists.fedorapro... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Thank you for the info!
On úterý 2. května 2023 22:17:13 CEST Kevin Fenzi wrote:
Greetings everyone.
Fedora Release engineering was made aware recently that some real builds seemed to have been done from commits not in any branch in the main repository for the package. All cases we are currently aware of were maintainers mistakenly building from a forked repo with a valid pull request.
On investigation, this was found to be due to some changes in how koji does the buildSRPMFromSCM task and us being unaware of the implications of that change.
In short, when a pull request is created, pagure keeps track of those commits in refs/pulls. Previously koji did a 'git reset' to the exact commit, which would only work for commits on a branch. The new method with 'git fetch' will follow refs and find the pull request commit.
Upstream koji developers have created a plugin for us to check policy after the checkout and require official builds to be from a commit that is in a branch. This plugin has been deployed and is active.
This seems like a thing that should be opt-out (for scratch builds e.g.), rather than opt-in by a plugin. Don't you have a link to the corresponding Koji change?
Pavel
Sorry for any confusion this issue may have caused.
kevin
On Wed, May 03, 2023 at 07:23:48AM +0200, Pavel Raiskup wrote:
Thank you for the info!
...snip...
This seems like a thing that should be opt-out (for scratch builds e.g.), rather than opt-in by a plugin. Don't you have a link to the corresponding Koji change?
It uses the koji hub 'scm' policy. Ours allows scratch builds.
https://pagure.io/fedora-infra/ansible/blob/main/f/roles/koji_hub/templates/...
I'll have to dig around for the koji PR... It should be in the next release I think.
On Wed, May 03, 2023 at 10:15:55AM +0200, Miro Hrončok wrote:
On 02. 05. 23 22:17, Kevin Fenzi wrote:
Upstream koji developers have created a plugin for us to check policy after the checkout and require official builds to be from a commit that is in a branch. This plugin has been deployed and is active.
Is the plugin disabled for scratch builds? If not, could it be?
It already allows them. ;)
kevin
On 02. 05. 23 22:17, Kevin Fenzi wrote:
Upstream koji developers have created a plugin for us to check policy after the checkout and require official builds to be from a commit that is in a branch. This plugin has been deployed and is active.
Is the plugin disabled for scratch builds? If not, could it be?