Its a lot to unpack, but in https://github.com/pnnl-miscscripts/miscscripts there are scripts to:
1. automatically build containers with newest versions of dependencies
2. apply a new version number only if the fingerprint of the software and its dependencies inside the container changes
3. push the updated images only when a new one exists.

Then it does the same for charts that point to the containers.

It essentially creates a repository that keeps everything up to date and doesn't cause spurious updates when unneeded.

It probably needs some work to be really generic. If someone were up for the challenge, that could benefit a lot of folks I think. Probably needs its own project. Currently I think its one of the biggest unsolved issues in the Cloud Native landscape. I'd be happy to contribute to such a project if there is interest in forming one.

Thanks,
Kevin

________________________________________
From: cncf-helm@... <cncf-helm@...> on behalf of Matt Farina <matt@...>
Sent: Monday, May 4, 2020 1:01 PM
To: cncf-helm@...
Subject: Re: [cncf-helm] Helm versioning and CI/CD

Berin,

I am not entirely sure of your workflow so these are just ideas and thoughts in the area.

First, appVersion is optional. You do not need to use it if you don't want to.

Second, if you are using the `helm package` command there are flags to pass in the version and appVersion.

Third, it is possible to alter things in CI. I was reminded of an example Antoine Legrand put together a few years ago. You can find it at https://gitlab.com/ant31/cookieapp/-/blob/master/.gitlab-ci.yml.<https://gitlab.com/ant31/cookieapp/-/blob/master/.gitlab-ci.yml>

The neat thing about the 3rd example is you can have a tag or even get a hash for a container image and then use that in the new chart version.

Does any of this help?

- Matt Farina

On Mon, May 4, 2020, at 1:17 PM, Loritsch, Berin wrote:
I'm in the process of writing up my recommendations for how to integrate Helm into our build and deployment infrastructure. I have a few questions that I need to understand better. The most important one has to do with how versions are intended to work with Helm.

There are two versions to worry about in any given helm file:

* Chart Version {{.Chart.version}}
* Application Version {{.Chart.appVersion}}

The way I understand it, Helm charts deal with _how_ something is deployed, and the container(s) itself deals with _what_ is deployed.

In a shop where we do continuous integration/continuous deployment we need to come up with the policies for how we manage versions. For example, we have the policy that containers are built and tagged based on the code branch or tag we are building from.

Since the chart has two version numbers embedded inside, I was wondering if there are command-line arguments to override any value. The chart itself is not going to change unless we find a defect in it. It would work with our CI/CD infrastructure if we overrode the .Chart.appVersion with the branch name when we do the full build.

If that is the case, we can build our chart as if it is production, and simply override versions when deploying specific versions of an application.

--
Berin Loritsch

Systems Integration Lead

[https://lh5.googleusercontent.com/F8VCu684Vc8-wD3bTezZ6MmgbGlabJADIpQVkdjrivp_Ey7jaQtylzhE3JxCzYYUXubtuukcibd98w8Q5PXvhnpvvg3uk_jZcrBOuXY4UItaHzhl6VusEmvfCQ3Rfdz7OeLhHOU3]<https://protect2.fireeye.com/v1/url?k=65b239c5-3907067c-65b213d0-0cc47adc5fce-fd48b812c6dd0008&q=1&e=9178ae48-7532-45cb-b0d2-c00df08d0862&u=http%3A%2F%2Fwww.novetta.com%2F>

7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...<mailto:bloritsch@...>

Office (703) 735-6281

Mobile (571) 215-7708