add packit config

[evgeni]

What are the changes introduced in this pull request?

adds support for packit (see https://community.theforeman.org/t/packit-for-foreman-get-production-rpms-from-prs/32412)

Considerations taken when implementing this change?

none

What are the testing steps for this pull request?

spin up a box

# dnf copr enable packit/katello-katello-<PR_NUMBER> centos-stream-8-x86_64
# dnf upgrade rubygem-katello

should give you a .rpm build of Katello from a PR :)

[evgeni]

seems someone (@ehelms?) gotta approve the org in Packit first -.-

[evgeni]

/packit build

[evgeni]

That built, but uses a version that will "always" higher than nightly, not sure I like it

[evgeni]

That built, but uses a version that will "always" higher than nightly, not sure I like it

stupid pre-release gems, I couldn't fix it without doing almost everything packit does manually, so, uh, let's not :)

[ehelms]

That built, but uses a version that will "always" higher than nightly, not sure I like it

stupid pre-release gems, I couldn't fix it without doing almost everything packit does manually, so, uh, let's not :)

What is it that packit is doing that we don't have control over? As we onboard more plugins as nightly projects, we are going to see this over and over. So I am left wondering if we need a fix from Packit?

[evgeni]

It's replacing the Version and Release entries, thus breaking our macro magic.

I found a way to make it stop, but then it's also not doing a few other changes to the spec file and that broke other stuff. I dan try having another look next week

[ofedoren]

Since I'm also trying to add packit to some project, I've got a question: is this line necessary? I mean, by https://packit.dev/docs/configuration/#upstream_tag_template it makes more sense if the tag contains something else along the version.

[evgeni]

It is not. It's just part of the template (as most projects/plugins use v{version}) and it felt more natural to set it "correctly" vs dropping

[lachmanfrantisek]

What is it that packit is doing that we don't have control over? As we onboard more plugins as nightly projects, we are going to see this over and over. So I am left wondering if we need a fix from Packit?

Hello all, Packit PO here..;)

I am happy to see you are configuring Packit for more and more Foreman projects! So, let us know if there is something we can improve to make your life easier. It makes sense to make a change on our side if there is something you are fighting in every single package.

Please, either create an issue or we can also set up a virtual meeting to discuss this. (If you want, we can also discuss how you can get more out of Packit...)

František

[evgeni]

That built, but uses a version that will "always" higher than nightly, not sure I like it

stupid pre-release gems, I couldn't fix it without doing almost everything packit does manually, so, uh, let's not :)

What is it that packit is doing that we don't have control over? As we onboard more plugins as nightly projects, we are going to see this over and over. So I am left wondering if we need a fix from Packit?

I think it now does "the right thing" when mangling around the spec file, and I've opened packit/packit#2038 and packit/packit#2040 to make those steps easier in the future.

[ehelms]

Where does the buildroot get specified? When we switch to Copr we will have repositories that were built against RHEL and I'd imagine we'd want to do the same across Packit?

[ehelms]

Did not mean to close this earlier, I have a later question I posted this as it stands works and is useful so I am going to merge.

[evgeni]

The targets is what effectively maps to buildroots/chroots.
If I read https://packit.dev/docs/configuration/upstream/copr_build#available-copr-build-targets correctly, as long as Copr offers rhel, we can configure it.