Add 2nd tag with major and minor versions to the image at kamu-web-ua #243
Conversation
metiletan
changed the title
| ######################################################################################### | ||
|
|
||
| .PHONY: kamu-web-ui | ||
| kamu-web-ui: | ||
| docker build \ | ||
| --build-arg KAMU_WEB_UI_VERSION=$(KAMU_WEB_UI_VERSION) \ | ||
| -t $(KAMU_WEB_UI_IMAGE):$(KAMU_WEB_UI_VERSION) \ | ||
| -t $(KAMU_WEB_UI_IMAGE):$(KAMU_WEB_UI_MAJOR_VERSION).$(KAMU_WEB_UI_MINOR_VERSION) \ |
There was a problem hiding this comment.
It's also necessary to push this new tag.
| @@ -5,13 +5,17 @@ IMAGE_REPO = ghcr.io/kamu-data | |||
| KAMU_WEB_UI_VERSION = $(shell cat ../package.json | jq -r '.version') | |||
| KAMU_WEB_UI_IMAGE = $(IMAGE_REPO)/kamu-web-ui | |||
|
|
|||
| KAMU_WEB_UI_MAJOR_VERSION = $(shell echo $(KAMU_WEB_UI_VERSION) | cut -d. -f 1) | |||
| KAMU_WEB_UI_MINOR_VERSION = $(shell echo $(KAMU_WEB_UI_VERSION) | cut -d. -f 2) | |||
There was a problem hiding this comment.
What is the overall intent here? Are you suggesting to only specify major.minor app version in charts, i.e. allowing the same chart to pull a newer patched application version?
Would this necessitate pull: Always in all deployments?
// Please include more context in PR description in future.
There was a problem hiding this comment.
Note taken on the more description.
TL;DR
The intent is to allow version skew between charts and applications. Setting Always pull policy will be required, but it's not a problem. Details bellow.
The intention is to make it possible to have a version skew between charts and applications and to avoid bumping chart versions every time there are new releases of applications and vice versa.
Always pull policy will be required, but it's not a problem. Details bellow.The charts will only reference the major.minor tag, therefore every x.y.* version of the chart will be compatible with x.y.* version of the app. If users want to Always have the latest patch version of applications it would indeed require them to set the image pull policy to Always. This imposes the necessity to keep compatibility between pods running different patch versions. The latter, however, is the basic requirement of smooth updates and rollbacks in k8s.
It's important to note that for any production environment, it is recommended, to set the image by its digest, not by the tag. Kamu charts allow that. In this case nothing but users control the strictly selected version of the image. In this scenario, the pull policy may be specified as IfNotPresent since digests always change.
There was a problem hiding this comment.
It's important to note that for any production environment, it is recommended, to set the image by its digest
This is exactly what I was wondering - whether this change was implying that we should deploy to prod while allowing version skew.
I agree this can be useful for quick setup and less important environments, but in prod I would like to know exactly which image is used by every single pod.
| kamu-web-ui/ | ||
|
|
||
|
|
||
| .PHONY: kamu-web-ui-push | ||
| kamu-web-ui-push: | ||
| docker push $(KAMU_WEB_UI_IMAGE):$(KAMU_WEB_UI_VERSION) | ||
| docker push $(KAMU_WEB_UI_IMAGE):$(KAMU_WEB_UI_MAJOR_VERSION).$(KAMU_WEB_UI_MINOR_VERSION) | ||
| docker tag $(KAMU_WEB_UI_IMAGE):$(KAMU_WEB_UI_VERSION) $(KAMU_WEB_UI_IMAGE):latest |
There was a problem hiding this comment.
@sergiimk Is there any particular reason this latest tag is added here and not during the build stage?
There was a problem hiding this comment.
No reason. Ideally I wanted to avoid producing a bunch of tags locally and only tag during push, but unfortunately docker does not allow something like docker push <image> -t <name1> -t <name2> -t <name3>.
Feel free to move to build phase for consistency.
…-ui stage