How To Release

The steps for preparing for a new release are the following:

When the main repository contributors agree on releasing a new version, create a GitHub Release based on master and using the appropriate version according to the semantic versioning (e.g. 0.1.1). Use the version as tag and as the release title. In the description, enumerate the changes of the release, i.e., bug fixes, new features, changes, etc.

Once the release is created, a new git tag will be automatically created. Make sure that Github Action correctly identifies the tag (i.e. the job header should explicitly show "Tag 0.1.1") and triggers deploy stage that will push the Docker image to Docker Hub. Review the log and check out Docker Hub to make sure that the new operator image has been uploaded successfully.

If the Travis build job has failed for an external reason (e.g. a network issue, service unavailability), you can try triggering a rebuild. However, if the job has failed due to a coding issue (e.g. a problem in the workflow/ci.yaml, or in the Makefile), you will need to fix the issue and then build and push the Docker image manually.

Manual release

If the automated release process has failed for a coding issue, you can follow the next steps to release build and push the new operator release to the Docker registry.

1. Checkout the master branch

git checkout master

2. Pull the latest changes, including the new tag.

git pull origin master

3. Clean your working tree from untracked files, otherwise the released version will contain a -dirty suffix.

git clean -df

4. Build and push the Docker image

make push

5. Review the output log and go to the Docker registry to make sure that the image is pushed successfully and the tag is correct.