Configure Packit to handle downstream builds

[mkemel]

Adding configuration for Packit to:

1. Propose PR on https://src.fedoraproject.org/rpms/bluechi triggered by release on GH
2. Once merged (and thus new commit created in dist-git) - Koji and Bodhi updates will be triggered.

The .packit.yml configuration file should be updated in dist-git as well as part of the PR, so no need to create Packit configuration in dist git right now

[mkemel]

Using propose_downstream for SIG dist-git is WIP for Packit. Hopefully it will be available soon

[engelmi]

I think this is a good first step towards automating releases for BlueChi. However, I have a few questions on how this works and fits into our release process:
The propose_downstream will be triggered on "release" - so basically when pushing a new tag - and create a PR on https://src.fedoraproject.org/rpms/bluechi. It is going to create n PRs for all the branches due to the fedora-all and epel-all, right?
So the process then would be merging rawhide, which triggers koji and bodhi. If successful, merge PR for next version, and so on.
We still have to upload the tarball with the sources manually, right? Do we need to set up any credentials for triggering the koji/bodhi build?

[mkemel]

So the process then would be merging rawhide, which triggers koji and bodhi. If successful, merge PR for next version, and so on.

Yes.

We still have to upload the tarball with the sources manually, right?

No, Packit should do all the magic

Do we need to set up any credentials for triggering the koji/bodhi build?

No, Packit has the required permissions. There are more options that can be configured (e.g. trigger koji build also triggered by direct pushes to dist-git or merged PRs that were not created by Packit). But this configuration is a basic one and should do the trick for our (quite straightforward) process.

Unfortunately there is no way to really test it without running an actual upstream release. But having this inside we can make sure it works when releasing 0.10.
Similar configuration works for qm configured by @dougsland , adding him as a reviewer as well. During the latest release there was a small hiccup with latest fedora version bodhi update, but it was not an issue of the configuration, but of the Packit service itself.

[engelmi]

No, Packit should do all the magic

Where do we specify which tarball to use? Since we need git submodules for BlueChi, the default tarball created by GitHub doesn't contain these and the build would fail. We create a suitable tarball during the release pipeline. So we'd need to specify the tarball in the GH release as well as wait for the GH pipeline to finish.

No, Packit has the required permissions.

So they use an account and everything on their side of the service.

Unfortunately there is no way to really test it without running an actual upstream release. But having this inside we can make sure it works when releasing 0.10.

Yes, lets see how it will work for the next release. We can still fallback to manual and refine this further.

[mkemel]

Where do we specify which tarball to use?

In the specfile:
Source0: %{url}/releases/download/v%{version}/%{name}-%{version}.tar.gz
I think this is the correct one

So they use an account and everything on their side of the service.

Yes, you can look at qm releases - PRs in src.fedoraproject.com, koji builds and bodhi updates

We can still fallback to manual and refine this further.

Exactly

[mwperina]

Where do we specify which tarball to use?

In the specfile: Source0: %{url}/releases/download/v%{version}/%{name}-%{version}.tar.gz I think this is the correct one

Hmm, aren't we uploading this .tar.gz file to the github release manually to contain git submodules content? AFAIK github is not able in its automatic creation of source archive to include git submodules content ...

[mkemel]

@mwperina Hm, not sure about that, maintainer readme does not mention that. @engelmi ?
In any case, the build is triggered by release, so by the time it is created - we already have the tarball. Unless we upload it AFTER creating the release??

[engelmi]

Where do we specify which tarball to use?

In the specfile: Source0: %{url}/releases/download/v%{version}/%{name}-%{version}.tar.gz I think this is the correct one

Hmm, aren't we uploading this .tar.gz file to the github release manually to contain git submodules content? AFAIK github is not able in its automatic creation of source archive to include git submodules content ...

Yes, the default .tar.gz doesn't include the git submodules and we had to create it manually. This was automated a few months back and should work again (after the tokens were updated), see these CI steps.

[coveralls]

coverage: 80.899% (-0.09%) from 80.989%
when pulling 427784f on mkemel:packit
into 9ea7721 on eclipse-bluechi:main.

[engelmi]

LGTM

[mkemel]

I would really like for @dougsland to review this one before we merge

[mwperina]

LGTM