serverhorror
commented
1 year ago TL;DR -- If it doesn't block you I would like to avoid setting latest. It's a frowned upon practice and was deliberately removed for Helm rollouts.
- I suppose that is a bug? Or is this on purpose?
If I recall correctly this is on purpose. latest is quite frowned upon as it doesn't provide a stable reference.
I think the decision for the difference was based on:
- let's not break tailor while it is still in use (officially tailor doesn't support OCP4 anyway)
-
let's "encourage" better practices. Not setting a tag will make it so the
context.shortGitCommitis available (by default)- https://github.com/opendevstack/ods-jenkins-shared-library/blob/a6a84a3a6a012a07f4be8983932a189508379ab0/src/org/ods/component/TailorDeploymentStrategy.groovy#L106
- https://github.com/opendevstack/ods-jenkins-shared-library/blob/a6a84a3a6a012a07f4be8983932a189508379ab0/src/org/ods/component/HelmDeploymentStrategy.groovy#L94
- Why does this tagging actually happen in the Deployment stage and not in the Build stage? In my case, if I hadn't the Helm part and would just build an image without deploying it, it would never get tagged latest because I wouldn't use the deployment stage in the Jenkinsfile at all. I think I'm missing something here.
It does happen in the build stage. It tags with shortGitCommit and has done so for quite a while, this wasn't even touched when it comes to the Helm stuff.
The latest is a remnant of an old decision that we now have to live with. It was a bad idea in the first place:
- https://github.com/opendevstack/ods-jenkins-shared-library/blob/a6a84a3a6a012a07f4be8983932a189508379ab0/src/org/ods/component/BuildOpenShiftImageStage.groovy#L42
- https://github.com/opendevstack/ods-jenkins-shared-library/blob/a6a84a3a6a012a07f4be8983932a189508379ab0/src/org/ods/component/BuildOpenShiftImageStage.groovy#L77
- https://github.com/opendevstack/ods-jenkins-shared-library/blob/a6a84a3a6a012a07f4be8983932a189508379ab0/src/org/ods/component/BuildOpenShiftImageStage.groovy#L147
- Am I structuring this wrong, or lets say not as intended by ODS? If there is no solution to my problem I will probably just create an additional docker plain component in which I just build the docker image (so that the tailorDeploymentStrategy is used) and keep my current component just for the helm stuff. An issue will still be that the pipeline enforces me to have a deployment for my image even though I just want to build the image.
If you really only want to build and image, that is pretty unrelated to Helm at all. I'd drop everything that is related to tailor or Helm and just do something along those lines:
// guard build so we don't rebuild unless necessary
// use a stable, but predictable tag that won't give us trouble if we use the wrong `ImagePullPolicy` in our resource descriptions
odsComponentFindOpenShiftImageOrElse(context, [imageTag: context.shortGitCommit]) {
odsComponentStageBuildOpenShiftImage(context, [context.shortGitCommit])
}
// don't do any odsComponentStageRolloutOpenShiftDeployment at all!
renedupont
I provisioned a docker plain component and am using the Dockerfile and the Jenkins stage odsComponentStageBuildOpenShiftImage to just build the image. I deleted the DeploymentConfig in OCP because I really just want to build the image to have it in the registry. Additionally, I added a couple of kubernetes resources (a CronJob and a PVC yaml) into the repo and manage this via Helm (via stage odsComponentStageRolloutOpenShiftDeployment).
Since I added the Helm stuff my above image doesn't get tagged as latest anymore, which is unfortunate because I use this image in the CronJob. I looked into the ods code and saw that when using the tailorDeploymentStrategy it tags the image as latest here: ods-jenkins-shared-library/src/org/ods/component/TailorDeploymentStrategy.groovy at master · opendevstack/ods-jenkins-shared-library (github.com) while the same does not happen in the helmDeploymentStrategy at all.
Regarding this, I have the following questions:
To circumvent the issue, I'm currently setting the imageTag myself:
That works, but it is error prone. In case I update the Dockerfile but forget to raise these versions before pushing, it would overwrite the previous image in the registry. I would rather have it automatically tagged as latest.