Use helm dependency build in release build #563

justusbunsi · 2023-11-14T17:24:19Z

2023-11-14 17:24:19 +00:00

Using helm dependency update may result in unwillingly updating the
dependencies while cutting a release. I wasn't able to do so. Most
likely due to the dependency pinning in Chart.yaml and Chart.lock.

Based on Helm documentation, update uses Chart.yaml¹ while build
uses Chart.lock².
All in all it is safer to use helm dependency build. :D

Using `helm dependency update` may result in unwillingly updating the dependencies while cutting a release. I wasn't able to do so. Most likely due to the dependency pinning in Chart.yaml and Chart.lock. Based on Helm documentation, `update` uses Chart.yaml[^1] while `build` uses Chart.lock[^2]. All in all it is safer to use `helm dependency build`. :D [^1]: https://helm.sh/docs/helm/helm_dependency_update/ [^2]: https://helm.sh/docs/helm/helm_dependency_build/

justusbunsi added 1 commit 2023-11-14 17:24:19 +00:00

Use helm dependency build in release build

check-and-test / check-and-test (pull_request) Successful in 27s

Details

e8aaad527b

Using `helm dependency update` may result in unwillingly updating the dependencies while cutting a release. I wasn't able to do so. Most likely due to the dependency pinning in Chart.yaml and Chart.lock. Based on Helm documentation, `update` uses Chart.yaml[^1] while `build` uses Chart.lock[^2]. All in all it is safer to use `helm dependency build`. :D [^1]: https://helm.sh/docs/helm/helm_dependency_update/ [^2]: https://helm.sh/docs/helm/helm_dependency_build/ Signed-off-by: justusbunsi <sk.bunsenbrenner@gmail.com>

justusbunsi requested review from pat-s 2023-11-14 17:24:26 +00:00

justusbunsi requested review from techknowlogick 2023-11-14 17:24:31 +00:00

justusbunsi added the

kind

build

label 2023-11-14 18:21:58 +00:00

pat-s commented

2023-11-14 21:52:22 +00:00

Interesting. Shouldn't Chart.lock and Chart.yaml be in sync at all times? The former is created from the latter and I don't see how helm dependency update would change Chart.yaml if a fixed version is used.

However, if you make a manual change to Chart.yaml (e.g. to prepare an update) and run helm dependency build, you will get an error:

Error: the lock file (Chart.lock) is out of sync with the dependencies file (Chart.yaml). Please update the dependencies

which essentially means: "Use helm dependency update".

So I wonder: should we just stick to helm dependency update? What event motivated you too look into this in the first place?

Interesting. Shouldn't `Chart.lock` and `Chart.yaml` be in sync at all times? The former is created from the latter and I don't see how `helm dependency update` would change `Chart.yaml` if a fixed version is used. However, if you make a manual change to `Chart.yaml` (e.g. to prepare an update) and run `helm dependency build`, you will get an error: > Error: the lock file (Chart.lock) is out of sync with the dependencies file (Chart.yaml). Please update the dependencies which essentially means: "Use `helm dependency update`". So I wonder: should we just stick to `helm dependency update`? What event motivated you too look into this in the first place?

justusbunsi commented

2023-11-16 17:59:22 +00:00

@pat-s I probably confused you with the PR description. What I wanted to say:

Regenerating the charts folder is possible with both commands helm dependency build and helm dependency update.

For the build command: This is its sole purpose.
For the upgrade command: The charts folder will be build, but you are usually using this command for updating dependencies.

That's similar to npm install and npm update.

The intention of this PR is consistency within our builds. For releasing the chart, we simply need to regenerate the charts folder. There is no intention to update dependencies. So it would be consistent to use helm dependency build, not update.

So I wonder: should we just stick to helm dependency update? What event motivated you too look into this in the first place?

IMO, the continued usage of helm dependency update in our release workflow is risky. Maybe not right now as we have versions in bot Chart.yaml and Chart.lock preventing an unintended update.
I got there because I looked up what the release build does - in the context of #564. And then downloaded the released tar.gz file to make sure there was no implicit dependency update.

Using helm dependency build eliminates any doubts in the future. 🙂

@pat-s I probably confused you with the PR description. What I wanted to say: Regenerating the `charts` folder is possible with both commands `helm dependency build` and `helm dependency update`. - For the `build` command: This is its sole purpose. - For the `upgrade` command: The `charts` folder will be build, but you are usually using this command for updating dependencies. That's similar to `npm install` and `npm update`. The intention of this PR is consistency within our builds. For releasing the chart, we simply need to regenerate the `charts` folder. There is no intention to update dependencies. So it would be consistent to use `helm dependency build`, not `update`. > So I wonder: should we just stick to `helm dependency update`? What event motivated you too look into this in the first place? IMO, the continued usage of `helm dependency update` in our release workflow is risky. Maybe not right now as we have versions in bot Chart.yaml and Chart.lock preventing an unintended update. I got there because I looked up what the release build does - in the context of #564. And then downloaded the released tar.gz file to make sure there was no implicit dependency update. Using `helm dependency build` eliminates any doubts in the future. 🙂

pat-s approved these changes 2023-11-16 19:20:49 +00:00

pat-s left a comment

Thanks for the detailed clarification. All clear now!

👍 1

justusbunsi commented

2023-11-16 20:57:47 +00:00

@techknowlogick You wanna review or shall we merge?