-
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
stable: new release on 2020-08-11 (32.20200726.3.1) #158
Comments
This release adds the PXE |
Promotion PR - coreos/fedora-coreos-config#560 |
pipeline build failed:
Do we need coreos-installer 0.5.0-1.fc32 in stable as well? |
After looking at successful pipeline run, above errors looks like non-fatal. There is also timeout happening as well as just after that.
|
It's due to coreos/coreos-assembler#1643 (aka https://github.com/coreos/fedora-coreos-streams/issues/64). I've pushed a branch with cosa just before that PR. Once it's built, you can rebuild stable with this parameter:
Edit: for posterity, the error is in the console logs of those tests:
|
cosa image build with fcos-32.20200726.3.0 tag has finished. |
My bad, forgot to override COREOS_ASSEMBLER_IMAGE parameter during pipeline build, aborted it and started with right params - https://jenkins-fedora-coreos.apps.ci.centos.org/job/fedora-coreos/job/fedora-coreos-fedora-coreos-pipeline/13573/ |
Re-triggered build job with typo fix in build parameter COREOS_ASSEMBLER_IMAGE |
signing failed:
Started new pipeline build with force - https://jenkins-fedora-coreos.apps.ci.centos.org/job/fedora-coreos/job/fedora-coreos-fedora-coreos-pipeline/13578/ |
Failed during ostree signing.
Looks like this is not a glitch, I am going to stop retrying build unless we know the cause. |
I spun a testing-devel and it got past signing now so hopefully we're back to a good state. Want to try to kick off a new round of builds ? |
started another pipeline build - https://jenkins-fedora-coreos.apps.ci.centos.org/job/fedora-coreos/job/fedora-coreos-fedora-coreos-pipeline/13581/ |
and... I killed it 😢 - we found an issue with the rootfs artifacts that needs to be fixed.
So we're working on fixing that first. |
We found an issue with the PXE rootfs artifact where coreos-installer can't verify it [1]. We're going to do a new set of builds so let's stop the next/testing rollouts of 32.20200809.1.0 and 32.20200809.2.0 so we don't update users two times in as many days. [1] coreos#158 (comment)
We found an issue with the PXE rootfs artifact where coreos-installer can't verify it [1]. We're going to do a new set of builds so let's stop the next/testing rollouts of 32.20200809.1.0 and 32.20200809.2.0 so we don't update users two times in as many days. [1] #158 (comment)
another pipeline build with cosa having fixes for rootfs artifact - https://jenkins-fedora-coreos.apps.ci.centos.org/job/fedora-coreos/job/fedora-coreos-fedora-coreos-pipeline/13592/ |
started new build with force - https://jenkins-fedora-coreos.apps.ci.centos.org/job/fedora-coreos/job/fedora-coreos-fedora-coreos-pipeline/13595/ |
OSTree commit is present and has valid signature.
|
update rollout - #167 |
Incoming edges looks good in update graph |
rollout is scheduled to start at Wed 12 Aug 2020 03:30:00 PM UTC for duration of 48 hours |
rollout window is over, all nodes should be updated to latest stable stream |
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 --qemu-image /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 @{}
.sync-stream-metadata
job syncs the contents to S3NOTE: In the future, most of these steps will be automated.
Housekeeping
The text was updated successfully, but these errors were encountered: