5.2 KiB
Distribution
This section describes how to build and deploy publicly available releases of the Step CA.
Creating A New Release
New releases are (almost) entirely built and deployed by Travis-CI. Creating a new release is as simple as pushing a new github tag.
Definitions:
- Standard Release: ready for public use. no
-rc*
suffix on the version. e.g.v1.0.2
- Release Candidate: not ready for public use, still testing. must have a
-rc*
suffix. e.g.v1.0.2-rc
orv1.0.2-rc.4
-
Update the version of step/cli
$ dep ensure -update github.com/smallstep/cli
-
Commit all changes.
Make sure that the local checkout is up to date with the remote origin and that all local changes have been pushed.
$ git pull --rebase origin master $ git push
-
Tag it!
-
Find the most recent tag.
$ git fetch --tags $ git tag
The new tag needs to be the logical successor of the most recent existing tag. See versioning section for more information on version numbers.
-
Select the type and value of the next tag.
Is the new release a release candidate or a standard release?
-
Release Candidate
If the most recent tag is a standard release, say
v1.0.2
, then the version of the next release candidate should bev1.0.3-rc.1
. If the most recent tag is a release candidate, sayv1.0.2-rc.3
, then the version of the next release candidate should bev1.0.2-rc.4
. -
Standard Release
If the most recent tag is a standard release, say
v1.0.2
, then the version of the next standard release should bev1.0.3
. If the most recent tag is a release candidate, sayv1.0.2-rc.3
, then the version of the next standard release should bev1.0.3
.
-
-
Create a local tag.
# standard release $ git tag v1.0.3 ...or # release candidate $ git tag v1.0.3-rc.1
-
Push the new tag to the remote origin.
# standard release $ git push origin tag v1.0.3 ...or # release candidate $ git push origin tag v1.0.3-rc.1
-
-
Check the build status at Travis-CI.
Travis will begin by verifying that there are no compilation or linting errors and then run the unit tests. Assuming all the checks have passed, Travis will build Darwin and Linux artifacts (for easily installing
step
) and upload them as part of the Github Release.Travis will build and upload the following artifacts:
- step-certificates_1.0.3_amd64.deb: debian package for installation on linux.
- step-certificates_1.0.3_linux_amd64.tar.gz: tarball containing a statically compiled linux binary.
- step-certificates_1.0.3_darwin_amd64.tar.gz: tarball containing a statically compiled darwin binary.
- step-certificates.tar.gz: tarball containing a git archive of the full repo.
-
Update the AUR Arch Linux package
NOTE: if you plan to release
cli
next then you can skip this step.$ cd archlinux # Get up to date... $ git pull origin master $ make $ ./update --ca v1.0.3
-
Update the Helm packages
NOTE: This is an optional step, only necessary if we want to release a new helm package.
Once we have the docker images, we can release a new version in our Helm repository we need to pull the helm-charts project, and change the following:
- On step-certificates/Chart.yaml:
- Increase the
version
number (Helm Chart version). - Set the
appVersion
to the step-certificates version.
- Increase the
- On step-certificates/values.yaml:
- Set the docker tag
image.tag
to the appropriate version.
- Set the docker tag
Then create the step-certificates package running:
$ helm package ./step-certificates
A new file like
step-certificates-<version>.tgz
will be created. Now commit and push your changes (don't commit the tarball) to the master branch ofsmallstep/helm-charts
Next checkout the
gh-pages
branch.git add
the new tar-ball and update the index.yaml using thehelm repo index
command:$ git checkout gh-pages $ git add "step-certificates-.tgz" $ helm repo index --merge index.yaml --url https://smallstep.github.io/helm-charts/ . $ git commit -a -m "Add package for step-certificates " $ git push origin gh-pages
- On step-certificates/Chart.yaml:
All Done!
Versioning
We use SemVer for versioning. See the tags on this repository for all available versions.