Skip to content

Commit

Permalink
Add release process
Browse files Browse the repository at this point in the history
Copied from containernetworking/cni

The only difference is that the release archives also include the the
word "plugin"
  • Loading branch information
tomdee committed Jul 11, 2017
1 parent 56d8984 commit b7b0e6c
Show file tree
Hide file tree
Showing 2 changed files with 71 additions and 0 deletions.
35 changes: 35 additions & 0 deletions RELEASING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
# Release process

## Resulting artifacts
Creating a new release produces the following artifacts:

- Binaries (stored in the `release-<TAG>` directory) :
- `cni-plugins-<PLATFORM>-<VERSION>.tgz` binaries
- `cni-plugins-<VERSION>.tgz` binary (copy of amd64 platform binary)
- `sha1`, `sha256` and `sha512` files for the above files.

## Preparing for a release
1. Releases are performed by maintainers and should usually be discussed and planned at a maintainer meeting.
- Choose the version number. It should be prefixed with `v`, e.g. `v1.2.3`
- Take a quick scan through the PRs and issues to make sure there isn't anything crucial that _must_ be in the next release.
- Create a draft of the release note
- Discuss the level of testing that's needed and create a test plan if sensible
- Check what version of `go` is used in the build container, updating it if there's a new stable release.
- Update the vendor directory and Godeps to pin to the corresponding containernetworking/cni release. Create a PR, makes sure it passes CI and get it merged.

## Creating the release artifacts
1. Make sure you are on the master branch and don't have any local uncommitted changes.
1. Create a signed tag for the release `git tag -s $VERSION` (Ensure that GPG keys are created and added to GitHub)
1. Run the release script from the root of the repository
- `scripts/release.sh`
- The script requires Docker and ensures that a consistent environment is used.
- The artifacts will now be present in the `release-<TAG>` directory.
1. Test these binaries according to the test plan.

## Publishing the release
1. Push the tag to git `git push origin <TAG>`
1. Create a release on Github, using the tag which was just pushed.
1. Attach all the artifacts from the release directory.
1. Add the release note to the release.
1. Announce the release on at least the CNI mailing, IRC and Slack.

36 changes: 36 additions & 0 deletions scripts/release.sh
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
#!/usr/bin/env bash
set -xe

SRC_DIR="${SRC_DIR:-$PWD}"
BUILDFLAGS="-a --ldflags '-extldflags \"-static\"'"

TAG=$(git describe --tags --dirty)
RELEASE_DIR=release-${TAG}

OUTPUT_DIR=bin

# Always clean first
rm -Rf ${SRC_DIR}/${RELEASE_DIR}
mkdir -p ${SRC_DIR}/${RELEASE_DIR}

docker run -i -v ${SRC_DIR}:/opt/src --rm golang:1.8-alpine \
/bin/sh -xe -c "\
apk --no-cache add bash tar;
cd /opt/src; umask 0022;
for arch in amd64 arm arm64 ppc64le s390x; do \
CGO_ENABLED=0 GOARCH=\$arch ./build.sh ${BUILDFLAGS}; \
for format in tgz; do \
FILENAME=cni-plugins-\$arch-${TAG}.\$format; \
FILEPATH=${RELEASE_DIR}/\$FILENAME; \
tar -C ${OUTPUT_DIR} --owner=0 --group=0 -caf \$FILEPATH .; \
if [ \"\$arch\" == \"amd64\" ]; then \
cp \$FILEPATH ${RELEASE_DIR}/cni-${TAG}.\$format; \
fi; \
done; \
done;
cd ${RELEASE_DIR};
for f in *.tgz; do sha1sum \$f > \$f.sha1; done;
for f in *.tgz; do sha256sum \$f > \$f.sha256; done;
for f in *.tgz; do sha512sum \$f > \$f.sha512; done;
cd ..
chown -R ${UID} ${OUTPUT_DIR} ${RELEASE_DIR}"

0 comments on commit b7b0e6c

Please sign in to comment.