-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
testing: new release on 2020-06-11 (32.20200601.2.2) #119
Comments
This is a build done to pull in fixes that address coreos/fedora-coreos-tracker#525 by removing the modular repos as inputs to the rpm-ostree compose. |
The ostree import failed because the old coreos-ostree-importer was still running in the phx2 datacenter and accepting some of the requests (via fedmsg). It failed to import, which was good because it allowed us to identify this problem and fix it. I've manually kicked coreos-ostree-importer and the import was successful. I also manually started AWS/GCP kola runs. |
PR to stop rollouts for testing/next: #121 |
|
Ok the rollout is scheduled for 7am EDT on 06/15/2020 |
Going to close this out since all seems to be going well. |
First, verify that you meet all the prerequisites
Name this issue
testing: new release on YYYY-MM-DD
with today's date. Once the pipeline spits out the new version ID, you can append it to the title e.g.(31.20191117.2.0)
.Pre-release
Promote testing-devel changes to testing
From the checkout for
fedora-coreos-config
(replaceupstream
below withwhichever remote name tracks
coreos/
):git fetch upstream
git checkout testing
git reset --hard upstream/testing
/path/to/fedora-coreos-releng-automation/scripts/promote-config.sh testing-devel
git show
testing
branch on https://github.com/coreos/fedora-coreos-configBuild
testing
, leave all other defaults)Sanity-check the build
Using the the build browser for the
testing
stream:testing
release (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 upgrade
will have the new update.Run the release job
testing
and the new version IDcosa run -d /path/to/previous.qcow2
) and verifying thatrpm-ostree upgrade
works andrpm-ostree status
shows a valid signature.At 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)
From a checkout of this repo:
updates/testing.json
:rollout
has astart_percentage
of1.0
) and set itsversion
to the most recent completed rolloutversion
field to the new versionstart_epoch
field to a future timestamp for the rollout start (e.g.date -d '2019/09/10 14:30UTC' +%s
)start_percentage
field to0.0
duration_minutes
field to a reasonable rollout window (e.g.2880
for 48h)last-modified
field to current time (e.g.date -u +%Y-%m-%dT%H:%M:%SZ
)A reviewer can validate the
start_epoch
time by runningdate -u -d @<EPOCH>
. An example of encoding and decoding in one step:date -d '2019/09/10 14:30UTC' +%s | xargs -I{} date -u -d @{}
.sync-stream-metadata
job syncs the contents to S3NOTE: In the future, most of these steps will be automated.
Open an issue for the next release
jira
label to the ticketThe text was updated successfully, but these errors were encountered: