Introduce release process #9

f1ames · 2023-10-18T07:59:11Z

This PR introduces release pipeline.

It's quite basic but should be enough for a start and as a good foundation to build on further.

How it works

There is a single action with two jobs:

First one builds and publishes docker images. And builds and publishes helm chart. Both are published to docker hub.
The 2nd one (which depends on the 1st one) creates GH release and publishes packaged helm chart and install.yaml (which is a result of helm template...). This way admission controller can be installed directly from GH too.

The action will run on tag being pushed to this repo (for testing purposes I just run it as PR part too).

The only required manual actions is running bump script and pushing changes to repo (as described in CONTRIBUTING guide - https://github.com/kubeshop/monokle-admission-controller/blob/f1ames/feat/release-flow/CONTRIBUTING.md#releasing).

As a result of a release, we got 3 artifacts published in Kubeshop dockerhub:

and GH release:

I'm only not sure about DockerHub OCI registry. I mean, usually with helm the steps are adding specific helm repo and installing chart:

helm repo add ...
helm repo install ...

And here we have single command to install the chart. I mean, this works and is according to the docs, but it's a bit different than usual installation flow.

Testing

You can see successful job runs and also artifacts/releases publish.

To test how users would use it, see README installation and usage sections.

Changes

Release job described above.
README update (see https://github.com/kubeshop/monokle-admission-controller/blob/f1ames/feat/release-flow/README.md)

Fixes

None.

Checklist

tested locally
added new dependencies
updated the docs
added a test

WitoDelnat · 2023-10-24T07:52:27Z

.github/workflows/release.yaml

+          VERSION: ${{ env.VERSION }}
+        run: |
+          echo "Building Docker server image with version: ${VERSION}"
+          docker build -t kubeshop/monokle-admission-controller-server:latest -t kubeshop/monokle-admission-controller-server:${VERSION} ./admission-controller/server/


Is there a difference between kubeshop/monokle-admission-controller-server & kubeshop/monokle-admission-controller?

kubeshop/monokle-admission-controller is a Helm chart while kubeshop/monokle-admission-controller-server is a Docker image for webhook server.

murarustefaan · 2023-10-24T08:17:10Z

.github/workflows/release.yaml

+      - name: Build and publish Docker image (init container)
+        env:
+          VERSION: ${{ env.VERSION }}
+        run: |
+          echo "Building Docker init image with version: ${VERSION}"
+          docker build -t kubeshop/monokle-admission-controller-init:latest -t kubeshop/monokle-admission-controller-init:${VERSION} ./admission-controller/init/
+          docker push kubeshop/monokle-admission-controller-init:${VERSION}
+          docker push kubeshop/monokle-admission-controller-init:latest
+
+      - name: Build and publish Docker image (server container)
+        env:
+          VERSION: ${{ env.VERSION }}
+        run: |
+          echo "Building Docker server image with version: ${VERSION}"
+          docker build -t kubeshop/monokle-admission-controller-server:latest -t kubeshop/monokle-admission-controller-server:${VERSION} ./admission-controller/server/
+          docker push kubeshop/monokle-admission-controller-server:${VERSION}
+          docker push kubeshop/monokle-admission-controller-server:latest


Why not use the docker GH actions that are designed for this exact purpose of building and pushing a docker image? They also bring the benefit of layer caching, which reduces the amount of time we spend building.

Furthermore, why not build these docker images in separate actions?
I think there's a benefit in that by not building the initContainer image each time as that will probably not change as often as the main image.

Why not use the docker GH actions that are designed for this exact purpose of building and pushing a docker image? They also bring the benefit of layer caching, which reduces the amount of time we spend building.

Agree, I'll be happy to improve it. I just went with quite basic version to not spend too much time on it. Do you mean to use something like buildx (https://docs.docker.com/build/cache/backends/gha/), also similarly we have here - https://github.com/kubeshop/monokle-saas/blob/e3efa7c43904aac4f64bd1f4b27abe99dbd7a6d5/.github/workflows/api-renderers.yml#L41-L61?

Furthermore, why not build these docker images in separate actions?
I think there's a benefit in that by not building the initContainer image each time as that will probably not change as often as the main image.

The idea was to have separate image version for each release, but I guess it can be done just by tagging already built/existing images if it's source was not modified? (not sure, about Helm in DockerHub OCI registry, haven't found a way to add multiple tags to single version 🤔).

I can somehow see why we would want the same version on both, but on the other hand it does not necessarily make sense to version the initContainer if it does not actually change. IDK, @WitoDelnat, what do you think?

I'd keep the versions separated. There is little benefit to having them being the same. If you have problems with certificates it can even help to see if the init container changed (meaningfully).

As for the Helm Chart versioning I'm a bit more hesitant. Do we want to publish a new Chart for each Docker Image or leave the image as a variable in the values.yaml and default it to latest. @murarustefaan you have knowledge about current best practices?

Sure. TBH I have not seen a lot of projects linking the Chart and App Versions, they are separated for a reason.
Chart version should change only on Chart modifications, while
App Version should change alongside the image version. Here I would link the App Version to the admission controller version (which should be configurable trough values, just in case) while leaving the init container set to latest.

After discussing further with @murarustefaan I extracted an issue, since it seems to be broad topic and it's difficult to know what will be really useful at this stage - #13.

For improvements:

Changed to multi-stage images - e5eb0f4

Utilized buildx action for docker related logic - e98d709

Added build cache and restructured job - 1802bcd

murarustefaan · 2023-10-24T08:19:22Z

.github/workflows/release.yaml

+  create-release:
+    runs-on: ubuntu-latest
+    needs: build-and-push
+
+    steps:
+      - name: Extract version from tag
+        id: extract_version
+        run: echo "VERSION=${GITHUB_REF#refs/tags/v}" >> $GITHUB_ENV
+
+      - name: Debug version
+        run: echo ${{ env.VERSION }}
+
+      - name: Checkout Repository
+        uses: actions/checkout@v2
+
+      - name: Build release artifacts
+        env:
+          VERSION: ${{ env.VERSION }}
+        run: |
+          helm package ./helm --version ${VERSION}
+          helm template ./helm --version ${VERSION} > install.yaml
+          mv monokle-admission-controller-${VERSION}.tgz helm.tgz
+
+      - name: Create release and upload artifacts
+        uses: ncipollo/release-action@v1
+        with:
+          name: "Release ${{ env.VERSION }}"
+          allowUpdates: true
+          artifacts: 'install.yaml,helm.tgz'
+          omitBody: true
+          token: ${{ secrets.CI_BOT_TOKEN }}


Similarly, this could be a separate job for creating the manifest release only on changes to the manifest files (or on demand).

Probably the answer will be the same as in the comment above:

The idea was to have separate version for each release.

And here, creating manifest seems pretty cheap/fast. I guess reusing ones (based on changes) would be very similar when it comes to time/resources consumed? Unless you had something different in mind?

Ok, maybe because I went with, kind of, coupling manifest version with container versions. Still, if any container version is updated and released, manifests needs to be released to point to latest images.

The other way around not necessarily, so changes in manifests (Helm chart) only, should't result in new docker images. Probably that's what you had in mind? 🤔

murarustefaan

lgtm!

f1ames force-pushed the f1ames/feat/release-flow branch from 3ff12ba to 6d50591 Compare October 18, 2023 08:09

f1ames changed the title ~~Introduce release process~~ Introduce release process [WIP] Oct 18, 2023

f1ames force-pushed the f1ames/feat/release-flow branch from 6d50591 to 394ae76 Compare October 18, 2023 08:25

f1ames mentioned this pull request Oct 19, 2023

Add deployment scripts #8

Merged

4 tasks

Base automatically changed from f1ames/feat/deployment to main October 19, 2023 12:54

f1ames added 13 commits October 19, 2023 15:28

ci: draft release job [WIP]

5596650

chore: test release CI job [WIP]

33f18b4

chore: add bump script

4002366

refactor: improve release CI job

5a99dd9

chore: use 0.0.1 as starting version

87fb5c3

chore: test release job

676001d

ci: fix release step

4e867e9

chore: test release job, take 2

393205c

fix: fix chart image path

29b1f41

chore: update README [WIP]

38f95c0

chore: update README

843f8e5

chore: update reamde install section on bump version

0ccdbc4

chore: add docs on releasing

b026cff

f1ames force-pushed the f1ames/feat/release-flow branch from 0335e85 to b026cff Compare October 19, 2023 13:28

chore: apply minor corrections

c114ef7

f1ames changed the title ~~Introduce release process [WIP]~~ Introduce release process Oct 19, 2023

f1ames marked this pull request as ready for review October 19, 2023 14:24

f1ames requested review from WitoDelnat and murarustefaan October 19, 2023 14:24

chore: get rid of Helm 3.8.0 info

2028387

WitoDelnat reviewed Oct 24, 2023

View reviewed changes

WitoDelnat approved these changes Oct 24, 2023

View reviewed changes

murarustefaan reviewed Oct 24, 2023

View reviewed changes

f1ames added 2 commits October 24, 2023 14:37

fix: use multi-stage builds

e5eb0f4

test: add delay between applying policies and resources

8855608

f1ames added 4 commits October 24, 2023 15:08

chore: update deps

6b0a9ee

ci: add and test buildx

e98d709

chore: fix pacakges license and author fields

9382c6a

refactor: rework release job

1802bcd

f1ames mentioned this pull request Oct 25, 2023

Iterate and improve release process #13

Open

chore: remove tmp test related steps from release action

cb228b3

f1ames requested a review from murarustefaan October 25, 2023 11:24

murarustefaan approved these changes Oct 25, 2023

View reviewed changes

f1ames merged commit 72bd24f into main Oct 25, 2023

f1ames deleted the f1ames/feat/release-flow branch October 25, 2023 11:34

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Introduce release process #9

Introduce release process #9

f1ames commented Oct 18, 2023 •

edited

Loading

WitoDelnat Oct 24, 2023

f1ames Oct 24, 2023

murarustefaan Oct 24, 2023

f1ames Oct 24, 2023

murarustefaan Oct 24, 2023

WitoDelnat Oct 24, 2023

murarustefaan Oct 24, 2023

f1ames Oct 25, 2023

murarustefaan Oct 24, 2023

f1ames Oct 24, 2023

f1ames Oct 24, 2023

murarustefaan left a comment

Introduce release process #9

Introduce release process #9

Conversation

f1ames commented Oct 18, 2023 • edited Loading

How it works

Testing

Changes

Fixes

Checklist

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

murarustefaan left a comment

Choose a reason for hiding this comment

f1ames commented Oct 18, 2023 •

edited

Loading