Release Checklist Template¶
As part of the release process, a new GitHub issue should be created with the contents below. See the release process page for details.
Release Checklist¶
First, follow the instructions on the release process RTD docs page.
Once complete, this is a set of checks to perform once you have a commit, tags, release, docs, and container image.
Once you have completed a release, the following should be true:¶
-
[ ] A
release-(numbered version)
branch exists inargoproj-labs/applicationset
- example: 'release-0.1.0'
- [ ] The release branch name should NOT contain the letter
v
(e.g. BAD:release-v0.1.0
, not like this!) - [ ] Confirm that, within the GitHub web UI, the branch says
This branch is 1 commit ahead of master.
, with that one commit being the release commit described below.
-
A release commit exists as the most recent commit of the
release-(version)
branch:- [ ] A commit with the message of
Release (version)
- Example:
Release v0.1.0
- The version string SHOULD contain the letter
v
, as above.
- Example:
- The commit should contain changes to:
- [ ]
manifests/install.yaml
- [ ]
manifests/install-with-argo-cd.yaml
- [ ]
manifests/base/kustomization.yaml
- [ ]
.github/workflows/ci-build.yaml
- [ ]
docs/Getting-Started.md
- [ ]
hack/verify-argo-cd-versions.sh
- [ ]
manifests/namespace-install-with-argo-cd/kustomization.yaml
- [ ]
- [ ] A commit with the message of
- [ ] A
v(version)
tag exists in theargoproj-labs/applicationset
repo- Example:
v0.1.0
- [ ] Ensure it matches the release commit above
- Example:
-
[ ] A
stable
tag exists, and points to the same release commit as above. -
[ ] Ensure that a GitHub
v(version)
GitHub Release exists, pointing to thev(version)
tag.- Tag must have
v
prefix, egv0.1.0
- Tag must have
-
[ ] Ensure that container image exists on quay.io with name 'argoproj/argocd-applicationset'
- [ ] Appears here: https://quay.io/repository/argoproj/argocd-applicationset
- [ ] With tag
v(version)
, egv0.1.0
- [ ] Tag must have
v
prefix, egv0.1.0
- [ ] Tag must have
- [ ] Verify that the tag update time references today's date
- [ ] Security scan should be green.
On the release-(version)
branch:¶
- [ ] Ensure the VERSION string matches the expected version
- [ ] The VERSION string should NOT begin with a
v
, (eg BAD:v0.1.0
)
- [ ] The VERSION string should NOT begin with a
- [ ] Ensure that kustomize.yaml under
manifests/namespace-install-with-argo-cd/kustomization.yaml
points to the desired Argo CD version. - [ ] Ensure that
install.yaml
andinstall-with-argo-cd.yaml
undermanifests/
points to the desired ApplicationSet version. - [ ] Ensure that
install.yaml
andinstall-with-argo-cd.yaml
undermanifests/
points to the desired Argo CD version.
Master branch checklist¶
- Ensure that a PR is opened on the master branch that:
- [ ] Increments the VERSION file (eg 0.1.0 to 0.2.0)
- [ ] Verify VERSION file does not contain the letter
v
as a prefix to the versio number
Doc checklist¶
- [ ] Ensure that https://readthedocs.org/projects/argocd-applicationset/versions/ points to the correct commit (commit that is at the HEAD of the release branch), for the
stable
andv(version)
versions. - [ ] Ensure that https://argocd-applicationset.readthedocs.io/ points to the new version, and contains the correct content
- Note: this may require a manually triggered build at rtd.io. See release process for details.
- [ ] Ensure that the Getting Start page at rtd.io includes references to
kubectl apply
which points to the correct applicationset controller version- Ensure that both Section A and Section B (of Install) are updated from pointing to
master
, to pointing tov(version)
. - On Stable
- On the version-specific page:
https://argocd-applicationset.readthedocs.io/en/(version)/Getting-Started/
- Example:
https://argocd-applicationset.readthedocs.io/en/v0.2.0/Getting-Started/
- Example:
- Ensure that both Section A and Section B (of Install) are updated from pointing to
Changelog and release notes¶
In the GitHub Releases tag:¶
- [ ] Ensure that the
v(version string)
release contains the features/change log for the particular version. This should be roughly the same content as goes into the CHANGELOG.md file.
On the release-(version)
branch:¶
- [ ] Ensure that CHANGELOG.md includes the new version information
On the master branch:¶
- [ ] Ensure that CHANGELOG.md includes the new version information
Live image testing¶
-
[ ] Apply
install.yaml
on a cluster, and confirm that it installs the correct image version- [ ] Confirm that all the pods start as expected.
- [ ] Confirm that the pod logs contain no errors
- [ ] Run ApplicationSet E2E tests against ApplicationSet controller installed via this method
- [ ] Confirm that the pod logs contain no errors after runnings the tests
-
[ ] Apply
install-with-argo-cd.yaml
on a cluster, and confirm that it installs the correct image version- [ ] Confirm that all the pods start as expected.
- [ ] Confirm that the pod logs contain no errors
- [ ] Run ApplicationSet E2E tests against ApplicationSet controller installed via this method
- [ ] Confirm that the pod logs contain no errors after runnings the tests
Communications¶
- [ ] Publish blog post (if applicable)
- [ ] Post to Slack