erabo/spiegel_podman
1
0
Fork 0
mirror of https://github.com/podman-container-tools/podman.git synced 2026-08-05 00:15:44 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

docs: update release process for GitHub Actions

Browse source 
Co-authored-by: Jan Rodák <hony.com@seznam.cz>
Signed-off-by: Nedd Chairi Muñoz <neddchairiweb@gmail.com>
This commit is contained in:
Nedd Chairi Muñoz 2026-07-11 16:52:39 +02:00 • committed by NeddM
parent ac46410007
commit c8b1db227a
1 changed files with 27 additions and 75 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

100
RELEASE_PROCESS.md
View file

@ -12,7 +12,7 @@ development efforts occur on the *main* branch. Branches with a
## Release workflow expectations ## Release workflow expectations
* You have push access to the [upstream podman repository](https://github.com/containers/podman.git), and the upstream [podman-machine-os repository](https://github.com/containers/podman-machine-os) * You have push access to the [upstream podman repository](https://github.com/podman-container-tools/podman.git), and the upstream [podman-machine-os repository](https://github.com/podman-container-tools/podman-machine-os)
* You understand all basic `git` operations and concepts, like creating commits, * You understand all basic `git` operations and concepts, like creating commits,
local vs. remote branches, rebasing, and conflict resolution. local vs. remote branches, rebasing, and conflict resolution.
* You have access to your public and private *GPG* keys. They should also be documented on our [release keys repo](https://github.com/containers/release-keys). * You have access to your public and private *GPG* keys. They should also be documented on our [release keys repo](https://github.com/containers/release-keys).
@ -81,32 +81,15 @@ spelled with complete minutiae.
If so, repeat above steps for `podman-machine-os`. If so, repeat above steps for `podman-machine-os`.
1. Back on the podman repo, automation will begin executing on the branch immediately. 1. Back on the podman repo, automation will begin executing on the branch immediately.
Because the repository allows out-of-sequence PR merging, it is possible that Because the repository allows out-of-sequence PR merging, it is possible that
merge order introduced bugs/defects. To establish a clean merge order introduced bugs/defects. To establish a clean baseline, observe
baseline, observe the initial CI run on the branch for any unexpected the initial GitHub Actions CI run on the branch for any unexpected failures.
failures. This can be done by going directly to The runs can be monitored from the repository's
`https://cirrus-ci.com/github/containers/podman/vX.Y` [Actions page](https://github.com/podman-container-tools/podman/actions).
1. If there are CI test or automation boops that need fixing on the branch, 1. If there are CI test or automation boops that need fixing on the branch,
attend to them using normal PR process (to *main* first, then backport attend to them using normal PR process (to *main* first, then backport
changes to the new branch). Ideally, CI should be "green" on the new changes to the new branch). Ideally, CI should be "green" on the new
branch before proceeding. branch before proceeding.
1. Create a new branch-verification Cirrus-Cron entry.
1. This is to ensure CI's VM image timestamps are refreshed. Without this,
the VM images ***will*** be permanently pruned after 60 days of inactivity
and are hard/impossible to re-create accurately.
1. Go to
[https://cirrus-ci.com/github/containers/podman](https://cirrus-ci.com/github/containers/podman)
and press the "gear" (Repository Settings) button on the top-right.
1. At the bottom of the settings page is a table of cron-job names, branches,
schedule, and recent status. Below that is an editable new-entry line.
1. Set the new job's `name` and `branch` to the name of new release branch.
1. Set the `expression` using the form `X X X ? * 1-6` where 'X' is a number
between 0-23 and not already taken by another job in the table. The 1-hour
interval is used because it takes about that long for the job to run.
1. Add the new job by pressing the `+` button on the right-side of the
new-entry line.
1. Create a new local working-branch to develop the release PR 1. Create a new local working-branch to develop the release PR
1. Ensure your local clone is fully up to 1. Ensure your local clone is fully up to
@ -160,24 +143,25 @@ spelled with complete minutiae.
should be `Bump to vX.Y.Z` (using the actual version numbers). should be `Bump to vX.Y.Z` (using the actual version numbers).
1. Push this single change to your GitHub fork, and make a new PR, 1. Push this single change to your GitHub fork, and make a new PR,
**being careful** to select the proper release branch as its base. **being careful** to select the proper release branch as its base.
1. Wait for all automated tests pass (including on an RC-branch PR). Re-running 1. Wait for all automated tests to pass (including on an RC-branch PR). Re-running
and/or updating code as needed. and/or updating code as needed.
1. In the PR, under the *Checks* tab, locate and clock on the Cirrus-CI 1. In the PR, under the *Checks* tab, a GitHub Actions [workflow](https://github.com/podman-container-tools/podman/actions/workflows/machine-os-pr.yml) will run.
task `Optional Release Test`. In the right-hand window pane, click This workflow opens a PR on the [podman-machine-os repo](https://github.com/podman-container-tools/podman-machine-os)
the `trigger` button and wait for the test to go green. *This is a to build VM images for the release, links that PR in a comment on the Podman PR,
critical step* which confirms the commit is worthy of becoming a release. and applies the `do-not-merge/wait-machine-os-build` label until the images are built
1. In the PR, under the *Checks* tab, a GitHub actions [task](https://github.com/containers/podman/actions/workflows/machine-os-pr.yml) will run. and published.
This action opens a PR on the [podman-machine-os repo](https://github.com/containers/podman-machine-os), which builds VM images for the release. The action will also link the `podman-machine-os` pr in a comment on the podman PR 1. Go to the `podman-machine-os` bump PR, by clicking the link in the comment, or by finding it in the [podman-machine-os repo](https://github.com/podman-container-tools/podman-machine-os/pulls).
This action also automatically applies the `do-not-merge/wait-machine-image-build` to the Podman PR, which blocks merging until VM images are built and published.
1. Go to the `podman-machine-os` bump pr, by clicking the link in the comment, or by finding it in the [podman-machine-os repo](https://github.com/containers/podman-machine-os/pulls).
1. Wait for automation to finish running 1. Wait for automation to finish running
1. Once you are sure that there will be no more force pushes on the Podman release PR, merge the `podman-machine-os` bump PR 1. Once you are sure that there will be no more force pushes on the Podman release PR, merge the `podman-machine-os` bump PR
1. Tag the `podman-machine-os` bump commit with the same version as the podman release. (git tag -s -m 'vX.Y.Z' vX.Y.Z) 1. Tag the `podman-machine-os` bump commit with the same version as the podman release. (git tag -s -m 'vX.Y.Z' vX.Y.Z)
1. Push the tag. 1. Push the tag.
1. The tag will automatically trigger a Cirrus task, named “Publish Image”, 1. The tag will automatically trigger the
to publish the release images. It will push the images to Quay and cut a release on the `podman-machine-os` repo. Wait for this task to complete. You can monitor the task on the [Cirrus CI dashboard](https://cirrus-ci.com/github/containers/podman-machine-os) [`release`](https://github.com/podman-container-tools/podman-machine-os/actions/workflows/release.yml)
GitHub Actions workflow. It publishes the images to Quay and creates a
GitHub release in the `podman-machine-os` repository. Wait for this
workflow to complete successfully.
1. Return to the Podman repo 1. Return to the Podman repo
1. The `do-not-merge/wait-podman-machine-os` label should be automatically 1. The `do-not-merge/wait-machine-os-build` label should be automatically
un-set once the `podman-machine-os` release is finished. un-set once the `podman-machine-os` release is finished.
1. Wait for all other PR checks to pass. 1. Wait for all other PR checks to pass.
1. Wait for other maintainers to merge the PR. 1. Wait for other maintainers to merge the PR.
@ -211,47 +195,15 @@ spelled with complete minutiae.
1. After the tag is pushed, an action to bump to -dev will run. A PR will be opened for this bump. Merge this PR if needed. 1. After the tag is pushed, an action to bump to -dev will run. A PR will be opened for this bump. Merge this PR if needed.
1. Locate, Verify release testing is proceeding 1. Verify release testing is proceeding
1. When the tag was pushed, an automated build was created. Locate this 1. After the tag is pushed, open the
by starting from [GitHub Actions page](https://github.com/podman-container-tools/podman/actions)
`https://github.com/containers/podman/tags` and finding the recent entry and locate the workflow runs associated with the new tag.
for the pushed tag. Under the tag name will be a timestamp and abbreviated 1. Monitor the `Release` workflow and ensure that all required jobs
commit hash, for example `<> 5b2585f`. Click the commit-hash link. complete successfully.
1. In the upper-left most corner, just to the left of the "Bump to vX.Y" 1. Keep the relevant workflow run open for monitoring during the remaining
text, will be a small status icon (Yellow circle, Red "X", or green check). release steps.
Click this, to open a small pop-up/overlay window listing all the status
checks.
1. In the small pop-up/overlay window, press the "Details" link on one of the
Cirrus-CI status check entries (doesn't matter which one).
1. On the following page, in the lower-right pane, will be a "View more details
on Cirrus CI" link, click this.
1. A Cirrus-CI task details page will open, click the button labeled
"View All Tasks".
1. Keep this page open to monitor its progress and for use in future steps.
1. Update Cirrus-CI cron job list
1. After any Major or significant minor (esp. `-rhel`) releases, it's critical to
maintain the Cirrus-CI cron job list. This applies to all containers-org repos,
not just podman.
1. Access the repo. settings WebUI by navigating to
`https://cirrus-ci.com/github/containers/<repo name>`
and clicking the gear-icon in the upper-right.
1. For minor (i.e. **NOT** `-rhel`) releases, (e.x. `vX.Y`), the previous release
should be removed from rotation (e.x. `vX.<Y-1>`) assuming it's no longer supported.
Simply click the trash-can icon to the right of the job definition.
1. For `-rhel` releases, these are tied to products with specific EOL dates. They should
*never* be disabled unless you (and a buddy) are *absolutely* certain the product is EOL
and will *never* ever see another backport (CVE or otherwise).
1. On the settings page, pick a "less used" time-slot based on the currently defined
jobs. For example, if three jobs specify `12 12 12 ? * 1-6`, choose another. Any
spec. `H`/`M`/`S` value between 12 and 22 is acceptable (e.x. `22 22 22 ? * 1-6`).
The point is to not overload the clouds with CI jobs.
1. Following the pattern of the already defined jobs, at the bottom of the settings
page add a new entry. The "Name" should reflect the version number, the "Branch"
is simply the newly created release branch name (must be exact), and the "Expression"
is the time slot you selected (copy-paste).
1. Click the "+" button next to the new-job row you just filled out.
1. Announce the release 1. Announce the release
1. For major and minor releases, write a blog post and publish it to blogs.podman.io 1. For major and minor releases, write a blog post and publish it to blogs.podman.io