stable: new release on 2024-04-09 (39.20240322.3.1) #879
Assignees
Labels
Comments
|
fast-track PR for rpm-ostree update for CVE-2024-2905 |
dustymabe
changed the title
|
Pipeline failed during signing but robosignatory did sign everything OK. I was able to get into the pod and do the verification by commented out the fedmsg parts: Pipeline failed during signing but robosignatory did sign everything OK. I was able to get into the pod and do the verification by commented out the fedmsg parts: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
First, verify that you meet all the prerequisites
Edit the issue title to include today's date. Once the pipeline spits out the new version ID, you can append it to the title e.g.
(31.20191117.3.0).Pre-release
Promote testing changes to stable
Add theok-to-promotelabel to the issueReview the promotion PR against thestablebranch on https://github.com/coreos/fedora-coreos-configOnce CI has passed, merge itManual alternative
Sometimes you need to run the process manually like if you need to add an extra commit to change something in
manifest.yaml. The steps for this are:git fetch upstreamgit checkout stablegit reset --hard upstream/stable/path/to/fedora-coreos-releng-automation/scripts/promote-config.sh testingstablebranch on https://github.com/coreos/fedora-coreos-configBuild
stable, leave all other defaults). This will automatically run multi-arch builds.Sanity-check the build
Using the the build browser for the
stablestream:stablerelease (in the future, we'll want to integrate this check in the release job)IMPORTANT: this is the point of no return here. Once the OSTree commit is
imported into the unified repo, any machine that manually runs
rpm-ostree upgradewill have the new update.Run the release job
stableand the new version IDAt this point, Cincinnati will see the new release on its next refresh and create a corresponding node in the graph without edges pointing to it yet.
Refresh metadata (stream and updates)
Rollout general guidelines
When setting a rollout start time ask "when would be the best time to react to
any errors or regressions from updates?". Commonly we select 2PM UTC so that the
rollout's start at 10am EST(±1 for daylight savings), but these can be fluid and
adjust after talking with the fedora-coreos IRC. Note, this is impacted by the
day of the week and holidays.
The later in the week the release gets held up due to unforeseen issues the more
likely the rollout time allocation will need to shrink or the release will need
to be deferred.
Manual alternative
fedora-coreos-stream-generatorbinary is up-to-date.From a checkout of this repo:
sync-stream-metadatajob syncs the contents to S3Update graph manual check
NOTE: In the future, most of these steps will be automated.
Housekeeping
The text was updated successfully, but these errors were encountered: