kicbase: Improve build and release process

The current version is v0.0.51 which does not make sense. Need to switch to standard semver updated based on the change type.

• Major version updated if we have incompatible change - we can use 1 like minikube
• Minor version updated for every release - we can start at 0 in the next release
• Patch version updated for every patch release - we can start at 0 in the next release

How kicbase image is updated - current

PR flow

1. Build new image with tag "v0.0.N--" in jenkins (Google infra)
2. Push image to "gcr.io/k8s-minikube/kicbase-builds" and "docker.io/kicbase/build"
3. Update HEAD to use the new tag.

If we have multiple kicbase PRs, they will conflict on the version change. After merging one PR, the other need to rebase and the image.

Release flow

1. Build new image from master with version "v0.0.N+1"
2. Push to "gcr.io/k8s-minikube/kicbase" and "docker.io/kicbase/kicbase"
3. Create PR to update version and bucket to use the new image

New way

Versions

• Current version: docker.io/kicbase/kicbase:v0.0.51 (minikube 1.39.0)
• Development version: `docker.io/kicbase/kicbase:1.0.0-dev.1.
• Release version: docker.io/kicbase/kicbase:1.0.0 (minikube 1.40.0)

Comparing versions

• 1.0.0 is considered newer than 1.0.0-dev.1.NNN
• 1.0.0-dev.1.NNN is considered newer than 0.0.51
• 1.0.0-dev.2.XXX is considered newer than 1.0.0-dev.1.YYY
  • check if semver compares this correctly.

Build in github actions

Use matrix to build images in parallel using fast native build, and slow cross compile for other architectures.

1. Build jobs

   • amd64: ubuntu-latest
   • arm64: ubuntu-latest-arm
   • ppc64le: ubuntu-latest or ubuntu-latest-arm
   • s390x: ubuntu-latest or ubuntu-latest-arm

2. Upload images as build artifacts

3. Create multi-arch manifest

4. Push to registry

PR flow

PR 1:

1. Build new image with tag "1.0.0-dev.1.XXX" in github actions
2. Push to "docker.io/kicbase/kicbase"
3. Update version to "1.0.0-dev.1.XXX"

PR 2:

1. Build new image with tag "1.0.0-dev.1.YYY"
2. Push to "docker.io/kicbase/kicbase"
3. Update version to "1.0.0-dev.1.YYY"

First merged PR wins, the other need to rebase and use new version "1.0.0-dev.2.NNN". Rebase requires rebuild of the image - this required and cannot be avoided since the previous PR modified the image content.

Release flow

1. Tag the current image "1.0.0-dev.42.23606" to "1.0.0"
2. Update version to "1.0.0"
3. Rebuild not needed - we ship the image tested since the last merged PR

Using prow to build images

We have prow configuration to build images, but this does not work for the current flow. Prow unpublished images cannot be accessed - they must be published somehow. The process is not clear and not clear why we need this complication.