Ci cd helm build

[YaphetKG]

• builds helm charts versioned by their version numbers in the Chart.yaml file
• pushes the helm packages to containers.renci.org/translator/<chart-name>:<chart-version>

This is mainly to address the gap with our branch to environment mapping. Where changes are not isolated perfectly per chart. And unwanted updates from develop branch making it into master.
Using chart versions we can actually track the charts individually.

Next steps , we would let itrb know that we are now using helm in oci registry so instead of pointing to branches in this repo they could do something like helm install containers.renci.org/translator/aragorn:0.0.1 where we can include the chart version for each environment as part of the request.

Important

On our part we should actively bump chart versions, so that all the new changes we have will be pushed to containers.renci.org without overriding the previous chart.

[EvanDietzMorris]

Very cool.. I'll look more closely when I get a chance. I do think it would be probably be good to just prevent it from overwriting an existing version in the helm repo if possible, to prevent accidents. For the pypi release actions for reasoner-transpiler, if it tries to push a version that exists already, it just fails and you can see that in the actions. I wonder if we could have it do that for this too.

[gaurav]

Will there be some way for the contents of the various values files to be inserted into OCI (e.g. helm package -f values-populated.yaml -f ncats-dev-values.yaml ...) -- if so, then the container will need to be secure enough to store database authentication information! -- or is that something NCATS will need to get from this repository when they deploy the Helm charts?

[EvanDietzMorris]

I think the idea is to still use values files with that kind of stuff for each different deployment, but the core charts and versions of images etc can be packaged. So instead of having different branches for different deployments, we just have a handful of values files that correspond to each, while different versions of the charts can live in the containers repo. I think we should also have a file on github where we keep track of what version of the chart should be on each deployment, and every time we make a request to change something on ITRB we can reference that file and send them the chart version that should be deployed on a given maturity level, and they will always apply the corresponding values file(s) on top of it.