-
Notifications
You must be signed in to change notification settings - Fork 24
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
stable: new release on 2020-04-21 (31.20200407.3.0) #83
Comments
Promotion PR - coreos/fedora-coreos-config#359 |
I had to kill that job because we needed to get a fix in first: coreos/fedora-coreos-releng-automation#102 |
ok the pipeline failed because this was the first ever import into the compose repo for stable:
I've done the releng thing and manually made that commit so that we should never see that error again. The only stage that runs after ostree import is Kola AWS tests. I manually started those here |
release job failed due to issue coreos/fedora-coreos-releng-automation#103 |
ostree commit looks good:
|
PR for streams and updates metadata - #89 |
all done, rollout should begin at Wed 22 Apr 2020 03:30:00 PM UTC |
One of the test node I had created has successfully rolled out to version 31.20200407.3.0 |
First, verify that you meet all the prerequisites
Name this issue
stable: 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.3.0)
.Pre-release
Promote testing changes to stable
From the checkout for
fedora-coreos-config
(replaceupstream
below withwhichever remote name tracks
coreos/
):git fetch upstream
git checkout stable
git reset --hard upstream/stable
/path/to/fedora-coreos-releng-automation/scripts/promote-config.sh testing
git show
stable
branch on https://github.com/coreos/fedora-coreos-configBuild
stable
, leave all other defaults)Sanity-check the build
Using the the build browser for the
stable
stream:stable
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
stable
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/stable.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 @{}
.NOTE: In the future, most of these steps will be automated and a syncer will push the updated metadata to S3.
The text was updated successfully, but these errors were encountered: