This section describes the typical release cycle of rkt:
This section shows how to perform a release of rkt.
Only parts of the procedure are automated; this is somewhat intentional (manual steps for sanity checking) but it can probably be further scripted, please help.
The following example assumes we're going from version 1.1.0 (v1.1.0
) to 1.2.0 (v1.2.0
).
Let's get started:
stage1/aci/aci-manifest.in
is the same version of appc/spec vendored with rkt. Otherwise, update it.git clean -ffdx && ./autogen.sh && ./configure --enable-tpm=no --enable-functional-tests && make && make check
should workscripts/changelog.sh
will help generating an initial list of changes. Correct/fix entries if necessary, and group them by category.The rkt version is hardcoded in the repository, so the first thing to do is bump it:
scripts/bump-release v1.2.0
.
This should generate two commits: a bump to the actual release (e.g. v1.2.0, including CHANGELOG updates), and then a bump to the release+git (e.g. v1.2.0+git).
The actual release version should only exist in a single commit!git diff HEAD^^
or similar.
As well as changing the actual version, it also attempts to fix a bunch of references in the documentation etc.Check out the release commit and build it!
git checkout HEAD^
should work. You want to be at the commit where the version is without "+git". Sanity check configure.ac (2nd line).export BUILDDIR=$PWD/release-build && mkdir -p $BUILDDIR && sudo BUILDDIR=$BUILDDIR ./scripts/build-rir.sh
release-build/target/bin/rkt version
ldd release-build/target/bin/rkt
: it can contain linux-vdso.so, libpthread.so, libc.so, libdl.so and ld-linux-x86-64.so but nothing else.ldd release-build/target/tools/init
: same as above.sudo BUILDDIR=$BUILDDIR ./scripts/build-rir.sh --exec=./scripts/pkg/build-pkgs.sh -- 1.2.0
(add correct version)Sign a tagged release and push it to GitHub:
GIT_COMMITTER_NAME="CoreOS Application Signing Key" GIT_COMMITTER_EMAIL="security@coreos.com" git tag -u $RKTSUBKEYID'!' -s v1.2.0 -m "rkt v1.2.0"
git push --tags
Now we switch to the GitHub web UI to conduct the release:
export RKTVER="1.2.0"
export NAME="rkt-v$RKTVER"
mkdir $NAME
cp release-build/target/bin/rkt release-build/target/bin/stage1-{coreos,kvm,fly}.aci $NAME/
cp -r dist/* $NAME/
sudo chown -R root:root $NAME/
tar czvf $NAME.tar.gz --numeric-owner $NAME/
cp release-build/target/bin/*.deb .
cp release-build/target/bin/*.rpm .
cp release-build/target/bin/stage1-coreos.aci stage1-coreos-$RKTVER-linux-amd64.aci
cp release-build/target/bin/stage1-kvm.aci stage1-kvm-$RKTVER-linux-amd64.aci
cp release-build/target/bin/stage1-fly.aci stage1-fly-$RKTVER-linux-amd64.aci
rkt project key must be used to sign the generated binaries and images.$RKTSUBKEYID
is the key ID of rkt project Yubikey. Connect the key and run gpg2 --card-status
to get the ID.
The public key for GPG signing can be found at CoreOS Application Signing Key and is assumed as trusted.
The following commands are used for public release signing:
for i in $NAME.tar.gz stage1-*.aci *.deb *.rpm; do gpg2 -u $RKTSUBKEYID'!' --armor --output ${i}.asc --detach-sign ${i}; done
for i in $NAME.tar.gz stage1-*.aci *.deb *.rpm; do gpg2 --verify ${i}.asc ${i}; done
Once signed and uploaded, double-check that all artifacts and signatures are on github. There should be 8 files in attachments (1x tar.gz, 3x ACI, 4x armored signatures).
Publish the release!
Clean your git tree: sudo git clean -ffdx
.
Now it's announcement time: send an email to rkt-dev@googlegroups.com describing the release. Generally this is higher level overview outlining some of the major features, not a copy-paste of the release notes. Use your discretion and see previous release emails for examples. Make sure to include a list of authors that contributed since the previous release - something like the following might be handy:
git log v1.1.0..v1.2.0 --pretty=format:"%an" | sort | uniq | tr '\n' ',' | sed -e 's#,#, #g' -e 's#, $#\n#'