Add packit copr_build job on commit

[ckelleyRH]

This commit extends the packit COPR builds that run in the CI for PRs to commits, both in forks prior to PR opening and on merge to master.

Example run in my fork: https://github.com/ckelleyRH/pki/runs/14586351933
Instructions for enabling it in your own fork: https://packit.dev/docs/guide/

As presented, the COPR builds in the fork go into the packit namespace like this: https://copr.fedorainfracloud.org/coprs/packit/ckelleyRH-pki-master/build/6118108/

...and presumably once merged, the on-commit job that will run will also do builds in the packit namespace.

I think the packit namespace is fine for the forks, but it would have been nicer if the on-commit to master builds went into @pki/master. It is possible to configure that, but then all the fork builds would also then go into there, and we don't want that. I haven't seen a way to conditionalise that though. I think it is fine for now though, unless anyone can think of a better way.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[lachmanfrantisek]

I think the packit namespace is fine for the forks, but it would have been nicer if the on-commit to master builds went into @pki/master. It is possible to configure that, but then all the fork builds would also then go into there, and we don't want that. I haven't seen a way to conditionalise that though. I think it is fine for now though, unless anyone can think of a better way.

Hello, Packit PO here..;)

Just to clarify. If you hardcode the Copr project, Packit will not allow fork builds in that Copr project. (If not allowed in the Copr settings.) You are right that it's now not possible to parametrise this for forks. (You can only enable the fork to use the very same Copr project.)

I would suggest staying with the builds in Packit's namespace if possible so you have both usecases covered and Packit can also handle chroot updates when needed for you.

Let us know if you need any help. (Maybe with setting up tests or the rest of the Fedora workflow?...;)

[fmarco76]

LGTM

[ckelleyRH]

I think the packit namespace is fine for the forks, but it would have been nicer if the on-commit to master builds went into @pki/master. It is possible to configure that, but then all the fork builds would also then go into there, and we don't want that. I haven't seen a way to conditionalise that though. I think it is fine for now though, unless anyone can think of a better way.

Hello, Packit PO here..;)

Hello! I am a very happy customer 😄

Just to clarify. If you hardcode the Copr project, Packit will not allow fork builds in that Copr project. (If not allowed in the Copr settings.) You are right that it's now not possible to parametrise this for forks. (You can only enable the fork to use the very same Copr project.)

Thanks for the clarification, good to know!

I would suggest staying with the builds in Packit's namespace if possible so you have both usecases covered and Packit can also handle chroot updates when needed for you.

Understood, thanks! The reason it would have been better to put the builds into @pki/master is because there is already a build that gets put in there via another mechanism. There will now be two sets of builds, which is a bit wasteful.

Let us know if you need any help. (Maybe with setting up tests or the rest of the Fedora workflow?...;)

I have found the documentation and examples sufficient so far to do what we need, so kudos for that. If I have questions as we start doing more complicated stuff I will definitely reach out, one of my colleagues has done so already and came back happy with that interaction. 👍

While I have your ear though, we are particularly interested in multi-package updates (packit/packit#1870) and CentOS Stream integration (packit/packit-service#2068). These things not being supported is why we didn't consider Packit earlier, so we are very pleased that they are on the agenda!

[ckelleyRH]

Thanks @fmarco76 !

[lachmanfrantisek]

While I have your ear though, we are particularly interested in multi-package updates (packit/packit#1870) and CentOS Stream integration (packit/packit-service#2068). These things not being supported is why we didn't consider Packit earlier, so we are very pleased that they are on the agenda!

Good to know who is interested in these! Dependencies will take us some time to design and do properly, but I can say that the CentOS Stream release syncing is currently being implemented..;) (Will let you know once it's ready.)

[ckelleyRH]

Good to know who is interested in these! Dependencies will take us some time to design and do properly, but I can say that the CentOS Stream release syncing is currently being implemented..;) (Will let you know once it's ready.)

Yeah the multi-package update is a tricky one. Glad to hear about CentOS Stream, looking forward to it 😄

[edewata]

There's a trailing backslash here and in propose_downstream above for RHEL 9, is this needed? I don't think it's causing any problem, just being OCD 😄

[lachmanfrantisek]

@edewata @ckelleyRH

This should do the trick as well:

     - "copr://@pki/master"

[ckelleyRH]

Thanks, that is much less gross than what I wrote!