GCS release process

General

Repos that need to cut a release
- Glusterfs (Do we build on top of Gluster-5 tag or HEAD of release-5 branch?)
- Glusterd2 (Is there a tag or master?)
- gluster-csi-driver
- Gluster-block (What’s the plan here?)
- Anthill
- Gluster-prometheus (Going forward)
Branch for release & edit image tags to lock down versions
Run regression on chosen artifacts (when we have it)
Tag release version
Prepare release notes
- Contents (Where do we get this info?)
- Major new features
- Fixes
- Known issues
Send out announce
Blog post (copy of announcement)

Ensure your version of GCS repo is up-to-date:
```
$ git checkout master
$ git pull
```
Create a release branch for the version:
```
$ git checkout -b release-0.3
```
Lock down container images (See below)

Commit fixed container image versions

$ git add <modified files>
$ git commit -s -S -m 'Lock container images for release'

Tag the release and provide a list of the significant changes in the annotation
```
$ git tag -s v0.3
```
Run tests using tagged version prior to pushing to GitHub
- Currently, this is just ensuring the Vagrant environment comes up w/ all components

Push the branch and tag to GitHub

$ git push upstream
$ git push upstream tag v0.3

Images to lock down (currently) are:
- gluster-csi-driver - deploy/templates/gcs-manifests/gcs-csi.yml.j2
- glusterd2-nightly - deploy/templates/gcs-manifests/gcs-gd2.yml.j2
Other images that are already version locked (no action required):
- Kubernetes csi containers
- etcd operator
How to lock down:
- Master uses “latest”, so we need to locate the image sha for that…
- With docker:
  - docker pull image:tag
  - docker inspect image:tag
  - SHA is available at: .ContainerConfig.Image
- With skopeo:
  - skopeo inspect docker://<image>:<tag>
  - SHA is available at .Digest
- Perform lockdown:
  - Replace image: <image>:<tag> with image: <image>@sha256:<hash>