On 06. 05. 22 17:37, Frantisek Lachman wrote:
On Fri, May 6, 2022 at 4:12 PM Miro Hrončok mhroncok@redhat.com 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:
- 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.
There might be more.
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:
- Require explicit opt-in in the config in dist-git.
- Implement the basic version.
- Gather some feedback and improve/extend. (We are here.)
- 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.
The problem is I have not explicitly opted in yet I am afraid this will block my work. Before a more robust solution is found, please at least provide me a way how I can temporarily disable this for python-ogr and packit in ~1 month when we plan to do the Python 3.11 rebuilds.
Here is a list of mentioned solutions sorted from the less-fragile to the most (IMHO).
- Automation only happens when maintainer explicitly starts it
- Automation only happens when a packit PR was merged*
- Automation only happens for non-provenpackagers
- 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
Ack, will subscribe.