On 06. 05. 22 15:50, Frantisek Lachman wrote:
Hi Miro,
👋
that's a really valid point that we should somehow resolve. Is this always the
case with the mass rebuilds that they should be left unbuilt or just with your
Python rebuilds?
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?
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.)
2) check the committer for not being a proven packager (Packit is not a proven
packager and we don't want to change that. We would like to have as few
permissions as possible.)
* I don't see any technical problem with the implementation here and personally
see this as a possible solution.
Provenpackagers would be excluded from using this for their own PRs then? And
as said previously, non-provenpackagers do need to make side tag rebuilds as
well. Or even add the builds to an existing Bodhi update, if that sounds more
familiar.
3) use a commit message to skip/trigger the build
* We can't inform everyone about this feature so skipping the build by commit
command is probably not a good idea.
* And forcing the commit structure to trigger the build makes it hard to use.
Agreed. Also, combined with %autochangelog, this would leak to the %changelog.
So it is not that easy to achieve.
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.
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
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
