Hello all,
You might have heard some rumours that the Packit team is working on automation for downstream activities you need to do when working on a new release of a package to Fedora. And the rumours are true – I am really pleased to announce that Packit now covers the whole workflow from upstream development to Bodhi update. We try to reduce the human interaction with the system to places where it’s needed and wanted and do all the mundane work and busy waiting for you.
If you want to take a look at how it works, here is a blog post showing this on one of our packages: https://packit.dev/posts/downstream-automation
We have used the automation ourselves for a couple of weeks for our packages[0] and already got bored of the releases. It’s too simple.
And if you haven’t heard about Packit at all, check our web page: https://packit.dev
We know that people can have different needs, so let us know what you think about it. And if you hit any issues or have any suggestions, get in touch with us – ideally, in #packit:fedora.im on Fedora Matrix or in form of an upstream issue created here: https://github.com/packit/packit-service/issues/new
On behalf of the Packit team, František
[0]: As an example, take a look at `packit` https://src.fedoraproject.org/rpms/packit/ or `python-ogr` https://src.fedoraproject.org/rpms/python-ogr/ package. You can also check the activities of the packit FAS user in Koji ( https://koji.fedoraproject.org/koji/userinfo?userID=4641) or Bodhi ( https://bodhi.fedoraproject.org/users/packit).
On 06. 05. 22 11:06, Frantisek Lachman wrote:
Hello all,
You might have heard some rumours that the Packit team is working on automation for downstream activities you need to do when working on a new release of a package to Fedora. And the rumours are true – I am really pleased to announce that Packit now covers the whole workflow from upstream development to Bodhi update. We try to reduce the human interaction with the system to places where it’s needed and wanted and do all the mundane work and busy waiting for you.
If you want to take a look at how it works, here is a blog post showing this on one of our packages: https://packit.dev/posts/downstream-automation https://packit.dev/posts/downstream-automation
We have used the automation ourselves for a couple of weeks for our packages[0] and already got bored of the releases. It’s too simple.
And if you haven’t heard about Packit at all, check our web page: https://packit.dev https://packit.dev
We know that people can have different needs, so let us know what you think about it. And if you hit any issues or have any suggestions, get in touch with us – ideally, in #packit:fedora.im http://fedora.im on Fedora Matrix or in form of an upstream issue created here: https://github.com/packit/packit-service/issues/new
Hey František.
I read that "If Packit sees a new commit in the configured dist-git branch, it submits a new build in Koji like maintainers usually do."
Does that mean that if a provenpackager (e.g. me) commits to rpms/python-ogr in order to rebuild the package in a side tag (e.g. f37-python for Python 3.11 rebuild), packit will build it in the regular target, preventing the side tag build from happening (the same NVR cannot be built multiple times in Koji)?
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?
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.)
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.
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.
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?
Thanks for bringing this up! František
On Fri, May 6, 2022 at 2:19 PM Miro Hrončok mhroncok@redhat.com wrote:
On 06. 05. 22 11:06, Frantisek Lachman wrote:
Hello all,
You might have heard some rumours that the Packit team is working on
automation
for downstream activities you need to do when working on a new release
of a
package to Fedora. And the rumours are true – I am really pleased to
announce
that Packit now covers the whole workflow from upstream development to
Bodhi
update. We try to reduce the human interaction with the system to places
where
it’s needed and wanted and do all the mundane work and busy waiting for
you.
If you want to take a look at how it works, here is a blog post showing
this on
one of our packages: https://packit.dev/posts/downstream-automation https://packit.dev/posts/downstream-automation
We have used the automation ourselves for a couple of weeks for our
packages[0]
and already got bored of the releases. It’s too simple.
And if you haven’t heard about Packit at all, check our web page: https://packit.dev https://packit.dev
We know that people can have different needs, so let us know what you
think
about it. And if you hit any issues or have any suggestions, get in
touch with
us – ideally, in #packit:fedora.im http://fedora.im on Fedora Matrix
or in
form of an upstream issue created here: https://github.com/packit/packit-service/issues/new
Hey František.
I read that "If Packit sees a new commit in the configured dist-git branch, it submits a new build in Koji like maintainers usually do."
Does that mean that if a provenpackager (e.g. me) commits to rpms/python-ogr in order to rebuild the package in a side tag (e.g. f37-python for Python 3.11 rebuild), packit will build it in the regular target, preventing the side tag build from happening (the same NVR cannot be built multiple times in Koji)?
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
On Fri, May 6, 2022 at 3:51 PM Frantisek Lachman flachman@redhat.com 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?
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.)
- 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.
- 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.
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?
The problem I see here is that it doesn't encompass many other situations, like commits by co-maintainers or members of groups that are maintainers of the package. For example, a non-provenpackager member of the @python-sig group who might work on the Python mass rebuild. Or a non-provenpackager co-maintainer needs to rebuild the package in a side tag for version bump X.
Option 1) sounds much better to me. Because if the commit is done by packit, it is definitely safe to trigger the build. If the commit is not done by packit, you just cannot know if it's safe or not.
Fabio
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:
- 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.)
- 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.
- 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
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.
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).
- 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
František
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.
On Fri, May 6, 2022 at 5:54 PM Miro Hrončok mhroncok@redhat.com wrote:
On 06. 05. 22 17:37, Frantisek Lachman wrote:
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.
After talking to Franta, we will try to resolve this next week and deploy to production on May 17th: our usual schedule.
Hope that works for you,
Tomas
On 06. 05. 22 18:18, Tomas Tomecek wrote:
On Fri, May 6, 2022 at 5:54 PM Miro Hrončok <mhroncok@redhat.com mailto:mhroncok@redhat.com> wrote:
On 06. 05. 22 17:37, Frantisek Lachman wrote: 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). >> >> 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 <https://github.com/packit/packit-service/issues/1490> Ack, will subscribe.After talking to Franta, we will try to resolve this next week and deploy to production on May 17th: our usual schedule.
Hope that works for you,
It does, thanks.
On Fri, May 6, 2022 at 4:12 PM Miro Hrončok mhroncok@redhat.com wrote:
On 06. 05. 22 15:50, Frantisek Lachman wrote:
- 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).
- 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
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
On 06. 05. 22 11:06, Frantisek Lachman wrote:
You can also check the activities of the packit FAS user in Koji (https://koji.fedoraproject.org/koji/userinfo?userID=4641 https://koji.fedoraproject.org/koji/userinfo?userID=4641) or Bodhi ( https://bodhi.fedoraproject.org/users/packit https://bodhi.fedoraproject.org/users/packit).
Could you also please fill in https://fedoraproject.org/wiki/User:Packit with some emergency contact information? See for example https://fedoraproject.org/wiki/User:Rhcontainerbot
Yes, sure. Thanks for the example.
František
On Fri, May 6, 2022 at 2:21 PM Miro Hrončok mhroncok@redhat.com wrote:
On 06. 05. 22 11:06, Frantisek Lachman wrote:
You can also check the activities of the packit FAS user in Koji (https://koji.fedoraproject.org/koji/userinfo?userID=4641 https://koji.fedoraproject.org/koji/userinfo?userID=4641) or Bodhi ( https://bodhi.fedoraproject.org/users/packit https://bodhi.fedoraproject.org/users/packit).
Could you also please fill in https://fedoraproject.org/wiki/User:Packit with some emergency contact information? See for example https://fedoraproject.org/wiki/User:Rhcontainerbot
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
On Fri, May 6, 2022 at 2:21 PM Miro Hrončok mhroncok@redhat.com wrote:
On 06. 05. 22 11:06, Frantisek Lachman wrote:
You can also check the activities of the packit FAS user in Koji (https://koji.fedoraproject.org/koji/userinfo?userID=4641 https://koji.fedoraproject.org/koji/userinfo?userID=4641) or Bodhi ( https://bodhi.fedoraproject.org/users/packit https://bodhi.fedoraproject.org/users/packit).
Could you also please fill in https://fedoraproject.org/wiki/User:Packit with some emergency contact information? See for example https://fedoraproject.org/wiki/User:Rhcontainerbot
Miro, thank you for the headsup, I filled in both our accounts:
https://fedoraproject.org/wiki/User:Packit https://fedoraproject.org/wiki/User:Packit-stg
I specifically did not mention any name so the accounts are tied to a team/project, and not a person. Hope that works, Tomas
-
Fabio Valentini -
Frantisek Lachman -
Miro Hrončok -
Tomas Tomecek