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.
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 ascontroller.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, ifREPO_TYPE=pr
, a specifiedCONTROLLER_CHART_VERSION
would be paired with thecontroller-pr
chart repo for attemptinghelm dependency build
, etc.