On Fri, May 6, 2022 at 4:12 PM Miro Hrončok <mhron...@redhat.com> 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
