On Fri, May 6, 2022 at 4:12 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
On 06. 05. 22 15:50, Frantisek Lachman wrote:
> 1) configurable allow-list / block list for committers (for the user and/or for
> the whole service)
> * For our projects, we would allow just the `packit` user that we use for
> submitting the dist-git pull requests.
> * We could probably react to just `packit` commits for all the users but I
> don't like this all-or-nothing approach. (That people are required to use all
> the Packit's features or none.)
So when the maintainer merges a packit PR, it would trigger the build but not
otherwise?
Wouldn't it be more transparent if the maintainer types a packit command to the
PR to merge+build+bodhi it when the CI passes? I even think I could use this
(if it does not require a config config file in upstream). The command could
even allow passing some options in the future (for setting unusual karma
limits, etc.)
This sounds like a great addition!
I personally adore the full automation and the fact that we don't need to use fedpkg (or CLI in general) to get bodhi updates for merged dist-git PRs.
Miro, you're right that the current automation doesn't play well with mass rebuilds and the proven packager workflow.
Correct me if I am wrong, but it seems to me that this feature was built with
limited knowledge of how *other people* use dist-git. In my view, this cannot
be fully automated for pushes. IMHO the action *must* be triggered by the
maintainer unless everybody is fully aware that pushes may trigger builds
depending on some externalities, which is unlikely to happen.
Folks use different strategies to maintain their packages or deliver work from upstream to Fedora. Some want the latest greatest all the time, some only update rawhide, etc.
Agreed that we *need* to fix this automation work to correctly account for mass rebuilds and the proven packager workflow.
Here is a list of mentioned solutions sorted from the less-fragile to the most
(IMHO).
1. Automation only happens when maintainer explicitly starts it
2. Automation only happens when a packit PR was merged*
3. Automation only happens for non-provenpackagers
4. Automation happens on every push (current way)
* this could be documented in the PR initial comment
It makes sense to me to update the current functionality and support 1) and 2) - we can easily create an allowlist for users and that would cover 1), 2) and 3).
Miro, thank you for your thorough feedback!
Tomas
_______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
