[skip-ci] Packit: Enable sidetags for bodhi updates

[lsm5]

Packit now has sidetag support for adding multiple builds into a single bodhi update.

Since we release c/ccommon, skopeo, buildah and podman often almoost simultaneously, we should release them to Fedora in a single bodhi update using sidetags so all builds can be tested together.

Does this PR introduce a user-facing change?

None

[lsm5]

Related PRs:

1. [skip-ci] Packit: Enable sidetags for bodhi updates common#2159
2. [skip-ci] Packit: Enable sidetags for bodhi updates skopeo#2421
3. [skip-ci] Packit: Enable sidetags for bodhi updates buildah#5730

[lsm5]

Related PRs:

1. [skip-ci] Packit: Enable sidetags for bodhi updates common#2159
2. [skip-ci] Packit: Enable sidetags for bodhi updates skopeo#2421
3. [skip-ci] Packit: Enable sidetags for bodhi updates buildah#5730

@containers/podman-maintainers PTAL . These 3 PRs as well as this very PR should be merged together (IOW, no releases in between) and cherrypicked to the release branches relevant to Fedora.
Ref: https://packit.dev/docs/fedora-releases-guide/releasing-multiple-packages

[Luap99]

Do we actually want buildah skopeo podman all in one update? All the patch versions are released on their own timing so if I understand the packit docs correctly you then have to manually trigger the bodhi updates for each of the patch releases?

I guess overall this make sense, i.e. we have important c-common config files in the rpm so shipping all of them at once ensure configs and docs match all our tools and allow for better testing but I am not sure if the patch (z) versions causes more work on your end.

[lsm5]

Do we actually want buildah skopeo podman all in one update?

Given we often release everything together except some of the z-ones, let's give this way a shot.

All the patch versions are released on their own timing so if I understand the packit docs correctly you then have to manually trigger the bodhi updates for each of the patch releases?

We shouldn't need manual bodhi updates. Instead we'll need a human to run /packit koji-tag --all-branches on the Fedora dist-git PRs for packages that don't need new builds. I feel this would be a lot less work than manual kojis and bodhis. The sidetag support is also very new in packit, and I think we'll be among the first ones to try it, if not the very first.

I guess overall this make sense, i.e. we have important c-common config files in the rpm so shipping all of them at once ensure configs and docs match all our tools and allow for better testing but I am not sure if the patch (z) versions causes more work on your end.

Let's see what the experience is like. Would also be a good datapoint for the packit devs.

[Luap99]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lsm5, Luap99

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Luap99,lsm5]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[lsm5]

/cherrypick v5.2

[openshift-cherrypick-robot]

@lsm5: #23927 failed to apply on top of branch "v5.2":

Applying: Packit: Enable sidetags for bodhi updates
Applying: Packit: split out ELN jobs and reuse fedora downstream targets
Using index info to reconstruct a base tree...
M	.packit.yaml
Falling back to patching base and 3-way merge...
Auto-merging .packit.yaml
CONFLICT (content): Merge conflict in .packit.yaml
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0002 Packit: split out ELN jobs and reuse fedora downstream targets
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

In response to this:

/cherrypick v5.2

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.