.. SPDX-FileCopyrightText: © 2020 Open Networking Foundation SPDX-License-Identifier: Apache-2.0 Release Process =============== Prerequisites ------------- SD-Core makes the following assumptions about the components are included in a release: Git tags """""""" Code receives Git tags as a part of the CI process * Tag content comes from a **VERSION** file within the repo, and tags are created only the version is a SemVer released version (example: ``1.2.3``, no ``-dev`` or ``-rc`` extensions) * Tagging is *only done by the CI system* (GitHub Actions), which pushes tags to git repos after a submit/merge of code which changes the **VERSION** file. * CI system enforces tag uniqueness - no two commits have the same released version tags. * You can't re-release or "fix" a version that has problem - make a new version with fixes in it. 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 ``latest`` or ``master``. * 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. * There are two sets of Docker images that are created * The first set of Docker images is created based on every Pull Request that is merged in the source code and the image has the following two tags: ``latest`` and ``master-hashId``, where the ``hashId`` is the short commit ID. These 2 images are pushed into the ``sdcore`` project in ``registry.aetherproject.org`` (https://registry.aetherproject.org/harbor/projects/9/repositories) * The second set is the official release image which is created only when there is a new code release (when **VERSION** file changed). This image is pushed to ``DockerHub`` (https://hub.docker.com/u/omecproject) and has a tag named ``rel-semver`` (e.g., rel-1.4.0). * Official images are only pushed to registries by the CI system * Increases repeatability of the process, and prevents human accidents. Helm charts """"""""""" * 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. Release Steps ------------- 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. Finally, the ``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: 1. Make the fix on the master branch of sdcore-helm-charts (assuming that it is required in both places). 2. 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). 3. Cherry-picked patchsets on that branch will be checked by the **sdcore-1.0** branch of tests. 4. When it passes, submitting the change will make a new 1.0.x release 5. 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. 6. 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-charts`` **VERSION** 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: 1. Develop a fix to the issue on the master branch, get it approved after passing master tests. 2. 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". 3. 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. 4. Update helm charts and go through the helm chart update process above