This section describes how to build and deploy publicly available releases of the Step CLI.
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 smallstep/certificates.
$ go get -u github.com/smallstep/certificates
-
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
-
Select the value of the next tag, but DON'T 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
.
-
-
-
Synchronize the versions of
cli
andcertificates
.NOTE: If you do not need to update the version of
certificates
required by thecli
at this time (and vice versa) then thank your lucky stars and move on to step 5.Buckle up and get your affairs in order because here be dragons.
NOTE: In the subsequent steps let A.B.C be the new tag for the
cli
repo and X.Y.Z be the new tag for thecertificates
repo.-
Complete steps 1 & 2 from the
certificates
distribution doc.Up to the part where a tag has been selected, but not applied.
-
Bump the version of
cli
in thecertificates
go.mod tovA.B.C
. -
Commit the change to go.mod. And push the tag.
$ git add go.mod; git commit -m "Bump version of cli to vA.B.C" $ git tag vX.Y.Z; git tag push
This pushed tag will break in Travis because
[email protected]
does not exist. That's okay. -
Bump the version of
certificates
in thecli
go.mod tovX.Y.Z
. -
Commit the change to go.mod. And push the tag.
$ git add go.mod; git commit -m "Bump version of cli to vX.Y.Z" $ git tag vA.B.C; git tag push
This tagged build will break in CI/CD because sum.golang.org has not yet had the chance to crawl and create an entry for the new tag.
-
Wait for
https://sum.golang.org/lookup/github.com/smallstep/[email protected]
to become available.Keep looking it up in the browser or
curl
ing it from the command line until it becomes available. ~10 - 20 mins. -
In Travis restart the failed, tagged build for
cli
through the UI.Now that the
sum.golang.org
entry forcli
is available the build should be able to proceed past downloading the dependencies. Builds ofcli
can take up to 15 minutes so sit tight. -
In Travis restart the failed, tagged build for
certificates
through the UI.Wait till the build of
cli
has completed successfully. Thestep-ca
dockerfile relies on thecli:latest
docker build. -
Run
go mod tidy
in bothcertificates
andcli
and commit and push the changes tomaster
.
-
-
Tag it!
NOTE: Skip this step if you've already tagged and pushed in the previous step.
-
Create a local tag.
$ git tag v1.0.3 # standard release ...or $ git tag v1.0.3-rc.1 # release candidate
-
Push the new tag to the remote origin.
$ git push origin tag v1.0.3 # standard release ...or $ git push origin tag v1.0.3-rc.1 # release candidate
Check the build status at Travis-CI.
-
All Done!
We use SemVer for versioning. For the versions available, see the tags on this repository.