We currently have the ability to inject any/all component commit SHAs for accessing and using the correlating Docker image artifacts, e.g., CONTROLLER_SHA=abc1234 would eventually get injected into the Workflow chart as controller.docker_tag=git-abc1234
We need a similar ability to inject any/all component chart versions for overriding the defaults in Workflow's requirements.yaml, e.g., CONTROLLER_CHART_VERSION=v2.12.1-20170329233450-sha.bbc97a2 would eventually get injected into the Workflow chart's requirements.yaml before publishing.
Current thought is the REPO_TYPE=[pr | dev] set for the Workflow publishing job would trickle down for all <COMPONENT>_CHART_VERSION env vars as well. So, if REPO_TYPE=pr, a specified CONTROLLER_CHART_VERSION would be paired with the controller-pr chart repo for attempting helm dependency build, etc.
From @vdice on March 30, 2017 16:34
We currently have the ability to inject any/all component commit SHAs for accessing and using the correlating Docker image artifacts, e.g.,
CONTROLLER_SHA=abc1234would eventually get injected into the Workflow chart ascontroller.docker_tag=git-abc1234We need a similar ability to inject any/all component chart versions for overriding the defaults in Workflow's
requirements.yaml, e.g.,CONTROLLER_CHART_VERSION=v2.12.1-20170329233450-sha.bbc97a2would eventually get injected into the Workflow chart's requirements.yaml before publishing.Current thought is the
REPO_TYPE=[pr | dev]set for the Workflow publishing job would trickle down for all<COMPONENT>_CHART_VERSIONenv vars as well. So, ifREPO_TYPE=pr, a specifiedCONTROLLER_CHART_VERSIONwould be paired with thecontroller-prchart repo for attemptinghelm dependency build, etc.Copied from original issue: deis/jenkins-jobs#348