On Fri, May 6, 2022 at 4:12 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > That is the case for any rebuilds that happen in side tags. Most recently e.g. > the boost rebuilds. Sometimes, maintainers do that for their own packages as > well, but provenpackagers do that at larger scale. For Python packages, that'll > be Python rebuilds, but for other packages it might be any other targeted rebuild. > > > I am thinking about multiple options here: > > > > 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? It can be done like this. Either as a default for the service or be able to configure it to work like this. > 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.) * We don't require upstream config at all for downstream jobs. (We load the config from the respective dist-git commit. * I am not sure if this should be the only way how to start the builds but doable from our side. > > We can probably think about this more, but the second option looks the best for > > me so far. Automation is not reduced and work for proven packagers is > > untouched. What do you think? Would this work for you? Or, do you have any > > better idea/solution? > > 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. We know that there are a lot of approaches around so we have chosen the following way: 1) Require explicit opt-in in the config in dist-git. 2) Implement the basic version. 3) Gather some feedback and improve/extend. (We are here.) 4) if needed/wanted, we can provide another way of turning this on. With the first point (explicit opt-in), people can decide if the current state works for them or not. There are already people happy with the basic version and since we have all the plumbing/messaging/... already done, we can now easily make it more complex. > 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 Thanks for the points, I've created an upstream issue on our issue tracker for that: https://github.com/packit/packit-service/issues/1490 František _______________________________________________ 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
