SD-Core makes the following assumptions about the components are included in a release:
Docker container images
All docker images are tagged based on their git tags.
For released versions, the CI system should prevent a Dockerfile from referencing a parent containers that are a moving target, such as
This allows a container to be rebuilt given an arbitrary git commit with fair confidence that it will result in the same code in the container.
Official images are only pushed to registries by the CI system
Increases repeatability of the process, and prevents human accidents.
Each chart may only contain references to released, SemVer tagged container images
Chart CI process must check that a chart version is unique - a chart can’t be created with the same version twice. This should be done against the chart repo.
All Helm charts are checked that the containers they use have a SemVer version tag
A branch is created on the Helm charts repo, with the abbreviated name of the release - for example sdcore-1.0.
To allow for future patches to go into the repo in a way that does not conflict with the version branch, each component repo’s VERSION file should have it’s minor version increased. (ex: 1.2.n to 1.3.0-dev, so future 1.3.n+1 component release can easily be created).
The same should be done on Helm charts in the chart repos post release, but the
versions there should not include a
-dev suffix because chart publishing
requires that every new chart version be unique and unsuffixed SemVer is a
more consistent release numbering pattern.
sdcore-helm-charts repo overall VERSION should also be incremented
to the next minor version (1.6.0-dev) on the master branch, so all 1.0.x
releases of the overall charts repo will happen on the sdcore-1.0 branch.
Creating releases on the 1.0.x branch
If a fix is needed only to the helm charts:
Make the fix on the master branch of sdcore-helm-charts (assuming that it is required in both places).
After the master tests pass, manually cherry-pick the fix to the sdcore-1.0 branch (the Chart version would be different, requiring the manual step).
Cherry-picked patchsets on that branch will be checked by the sdcore-1.0 branch of tests.
When it passes, submitting the change will make a new 1.0.x release
Update the documentation to reflect the chart changes, a description of the changes m, and increment the tag on the docs from 1.0.n to 1.0.n+1, to reflect the patch change.
If all the charts are updated and working correctly, create a new charts point release by increasing the 1.0.n VERSION file in the sdcore-helm-charts repo. This should be the same as the version in the documentation. Immediately make another patch that returns the
sdcore-helm-chartsVERSION to 1.0.n+1-dev, so that development patches can continue on that branch.
If a fix is needed to the components/containers that are included by the helm charts:
Develop a fix to the issue on the master branch, get it approved after passing master tests.
If it does not exist, create an sdcore-1.0 branch on the component repo, starting at the commit where the VERSION of the component used in 1.0 was created - this is known as “lazy branching”.
Manually cherry-pick to the sdcore-1.0 branch of the component, increment the patch version, and test with the sdcore-1.0 version of sdcore-system-tests and helm charts.
Update helm charts and go through the helm chart update process above