Release process should work both for the master branch and dedicated api-server branch

[mszostok]

Description

The release process should work both for the master and dedicated api-server branch.

The release is done by the Travis job. The current release process is documented here: https://github.com/kubernetes-sigs/service-catalog/wiki/Release-Process

AC

• release process for CRD only from master is working
• release process for the dedicated api-server branch is working

[adamwalach]

Description

Release process creates three types of artifacts:

• docker images
• svcat binaries
• helm charts

docker images

They are created for multiple platforms (amd64, arm, arm64, ppc64le, s390x) and for the following components: user-broker, test-broker, service-catalog.

Commits

For every commit on master branch we produce two images (for every platform and component) with following tags:

• canary 
• last_release-commit_nr-commit_id (ie: v0.2.5-1-gc8406fe)
  It is computed in Makefile:

  VERSION ?= $(shell git describe --tags --always --abbrev=7 --dirty)
  

  According to the manual: 'This command finds the most recent tag that is reachable from a commit'

Release

For every release we produce two images (for every platform and component) with following tags:

• latest
• release name (ie: v0.2.6)

svcat binaries

Svcat binaries are created for multiple platforms (darwin, linux, windows). Version strings are encoded in the path:

https://download.svcat.sh/cli/latest/darwin/amd64/svcat
https://download.svcat.sh/cli/VERSION/darwin/amd64/svcat

Commits

For every commit on master branch we produce two binaries versions (for every platform):

• canary 
• last_release-commit_nr-commit_id (ie: v0.2.5-1-gc8406fe)

Release

For every release we produce two binaries versions (for every platform):

• latest
• release name (ie: v0.2.6)

helm charts

For every release we produce helm charts for the following components: healthcheck, user-broker, test-broker, service-catalog. Chart version is hardcoded in Chart.yaml - it has to be manually changed before every release

What needs to be changed

On the api-server branch (old, deprecated version):

• in contrib/travis/deploy.sh change "latest" to "latest-apiserver" and "canary" to "canary-apiserver". Replace "master" with "api-server"
• in test/repo-sync.sh change "catalog" to "catalog-apiserver" and change the loop so we release only the "catalog-apiserver" chart, other charts will be released from the master branch
• change "charts/catalog" to "charts/catalog-apiserver" and modify all references in the docs
• in Makefile the MUTABLE_TAG needs to be changed from "canary" to "canary-apiserver"
• in "charts/catalog-apiserver/templates/_helpers.tpl" the fullname template needs to be changed from

  {{- printf "%s-%s" .Release.Name .Chart.Name | trunc 63 | trimSuffix "-" -}}
  

  to

  {{- printf "%s-catalog" .Release.Name | trunc 63 | trimSuffix "-" -}}
  

Summary

We should use the 0.2.X version line for future updates to the old api-server branch and start with 0.3.0 for the master (crd) line. Because we use the "git describe" command to get the version string - the number of changes in our release process is quite small.
In general new images and binaries for the old "apiserver" branch will have names appended with "apiserver". If someone is using the "latest" tag then during upgrade he will be migrated to the crd-based version.
If he wants to use the old "apiserver" line (and he wants to upgrade to a patched version that we may release in the future) he has to use the apiserver tag.
Helm chart doesn't have a latest tag (latest version is just the most recently pushed chart) so we need to change chart name in the old branch to "catalog-apiserver".
In my example I used a branch called "apiserver" but after some discussions I think its better to use a name taken from current release - "v2", if in the future we'll have next major release with breaking changes we may use the same naming scheme and maintain compatible release process.

I tested travis integration (https://travis-ci.com/awalach-org/service-catalog) on this forked project: https://github.com/awalach-org/service-catalog/tree/api-server .
All changes on the test 'apiserver 'branch can be seen here: https://github.com/kubernetes-sigs/service-catalog/compare/master...awalach-org:api-server?expand=1

Urls

URLs used currently by SC:

• https://quay.io/organization/kubernetes-service-catalog/
• svcat binary: https://download.svcat.sh/cli/latest/darwin/amd64/svcat
• helm chart: https://svc-catalog-charts.storage.googleapis.com/

URLs used for testing:

• https://quay.io/organization/kyma-service-catalog
• svcat binary: https://kymaservicecatalog.blob.core.windows.net/cli/canary-apiserver/darwin/amd64/svcat
• helm chart: https://kyma-service-catalog.storage.googleapis.com/index.yaml
• https://kyma-service-catalog.netlify.com