Skip to content

Using CI/CD variables instead of values file to override some variables

Brie Carranzarequested to merge
docs-bcarranza-replicacount-replicas into master

What does this MR do and why?

This MR updates the docs on customizing AutoDevOps to clarify that not all settings can be overridden with .gitlab/auto-deploy-values.yaml or the file specified as HELM_UPGRADE_VALUES_FILE.

In the customizing AutoDevOps docs on customizing values for the Helm chart, we say:

You can override the default values in the values.yaml file in the default Helm chart by either:

  • Adding a file named .gitlab/auto-deploy-values.yaml to your repository, which is automatically used, if found.
  • Adding a file with a different name or path to the repository, and setting the HELM_UPGRADE_VALUES_FILE CI/CD variable with the path and name.

This works for some values. However, if a value for replicaCount is specified in .gitlab/auto-deploy-values.yaml or the file specified as HELM_UPGRADE_VALUES_FILE, that value is not respected.

Workarounds: It is possible to control the number of replicas via one of the build and deployment CI/CD variables: REPLICAS. Setting the value of REPLICAS does work where setting replicaCount does not.

Additionally, setting HELM_UPGRADE_EXTRA_ARGS has worked in the past for another customer:

HELM_UPGRADE_EXTRA_ARGS="--set replicaCount=2"

From the It should be possible to override all values using a values file and replicaCount from .gitlab/auto-deploy-values.yaml is ignored issues, we know that this is expected behavior:

This means that some values cannot be customized using .gitlab/auto-deploy-values.yaml

The docs should be updated to clarify that setting things like replicaCount in .gitlab/auto-deploy-values.yaml or the file specified as HELM_UPGRADE_VALUES_FILE won't work.

There's some additional information about this in the Closed replicaCount from .gitlab/auto-deploy-values.yaml is ignored issue.

A number of customers have observed this behavior. GitLab team members with access to Zendesk can learn more in the tickets 🎫 :

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Brie Carranza

Merge request reports