The release process for ACK service controller
Remember that there is no single ACK binary. Rather, when we build a release for ACK, that release is for one or more individual ACK service controllers binaries, each of which are installed separately.
This documentation covers the steps involved for officially publishing a ACK service controller’s release artifacts.
Once ACK service controller changes are tested by the service team and they wish to release latest artifacts, service team only needs to create a new release for service-controller github repository with a semver tag (Ex: v0.0.1). Steps below show how to create a new release with semver tag.
Once the git repository is tagged with semver, a postsubmit prowjob builds
container image for ACK service controller and publish to public ecr repository
Same prowjob also publishes the Helm charts for the ACK service controller to
public ecr repository
What is a release exactly?
A “release” is the combination of a Git tag containing a SemVer version tag against this source repository and the collection of artifacts that allow the individual ACK service controllers included in that Git commit to be easily installed via Helm.
The Git tag points at a specific Git commit referencing the exact source code that comprises the ACK service controllers in that “release”.
The release artifacts include the following for one or more service controllers:
- Container image
- Helm chart
The container image is built and pushed with an image tag that indicates the
release version for the controller along with the AWS service. For example,
assume a release semver tag of
v0.1.0 that includes service controllers for
S3 and SNS. There would be two container images built for this release, one each
containing the ACK service controllers for S3 and SNS. The container images would
have the following image tags:
that the full image name would be
The Helm chart artifact can be used to install the ACK service controller as a Kubernetes Deployment; the Deployment’s Pod image will refer to the exact container image tag matching the release tag.
- Rebase $SERVICE-controller repo with latest code:
cd $GOSRC/github.com/aws-controllers-k8s export SERVICE=s3 cd $SERVICE-controller git fetch --all --tags # Optionally fetch and rebase the latest code generator cd ../code-generator git checkout main && git fetch --all --tags && git rebase upstream/main
- Navigate to $SERVICE-controller repo and check out a git branch for your release:
cd ../$SERVICE-controller export RELEASE_VERSION=v0.0.1 git checkout -b release-$RELEASE_VERSION git branch --set-upstream-to=origin/main release-$RELEASE_VERSION
- Navigate to code-generator repo and build the release artifacts for the $SERVICE-controller:
cd ../code-generator make build-controller
- Navigate to $SERVICE-controller repo to review the release artifacts that were built for each service by looking in the
cd ../$SERVICE-controller git diff
make build-controllerfor a service, it will overwrite any Helm chart files that had previously been generated in the
$SERVICE-controller/helmdirectory with files that refer to the container image with an image tag referring to the release you’ve just built artifacts for.
- Commit the generated release artifacts and create a pull request:
git commit -a -m "release artifacts for release $RELEASE_VERSION" git push origin release-$RELEASE_VERSION
Get your pull request reviewed and merged. After merge, tag is automatically applied and pushed.
git tagoperation (applied automatically in last step) triggers a postsubmit prowjob which builds container image and then publishes both container image and Helm chart to public ECR repository. Service team can see the release prowjobs, their status and logs at https://prow.ack.aws.dev/
The postsubmit prowjob mentioned above also publishes the stable Helm charts,
whenever there is a code push on
stable git branch. Follow the steps below
to cut a stable release for an ACK controller.
- Checkout the ACK controller release which will be marked as stable. Example below uses s3-controller v0.0.19 release.
cd $GOSRC/github.com/aws-controllers-k8s export SERVICE=s3 export STABLE_RELEASE=<v0.0.19-do-not-copy> #Update this tag for the specific controller cd $SERVICE-controller git fetch --all --tags git checkout -b stable-$STABLE_RELEASE $STABLE_RELEASE
- Update the helm chart version to the stable version. To learn more about nomenclature of stable branch and helm chart version please read our release phase guide.
For the above example, replace
version: v0.0.19 inside
version: v0-stable. Without this update the postsubmit prowjob will
fail because validation error due to chart version mismatch.
- Commit your changes from step2
git add helm/Chart.yaml git commit -m "Updating the helm chart version for stable release"
- Determine the remote which points to
aws-controllers-k8s/$SERVICE-controllerand not your personal fork. Execute
git remote --verbosecommand to find out the remote name. Example: In the command below,
originpoints to the
git remote --verbose origin https://github.com/aws-controllers-k8s/s3-controller.git (fetch) origin https://github.com/aws-controllers-k8s/s3-controller.git (push) vj https://github.com/vijtrip2/s3-controller.git (fetch) vj https://github.com/vijtrip2/s3-controller.git (push)
- Push the changes to the
stablebranch for remote pointing to
git push -u origin stable-$STABLE_RELEASE:stable
The above command will create a new
stable branch if it does not exist
and trigger the ACK postsubmit prowjob for stable release. This prowjob will
not build a container image and only publishes the helm artifacts with stable tag.
If the git push command fails, use
--force option to update the upstream
stable branch with your local changes.