Use per-project customized values.yaml file in auto devops .gitlab-ci.yml template (light version)
What does this MR do?
I want to share with you my solution for the issue #56961 (moved), it's a lighter version of my previous Merge Request !25687 (closed)
It allows to specify custom values.yaml
file per project / group / environment, this would allow to create re-usable framework specific helm charts when using Auto Deploy.
I think it can answer to both options proposed by @DylanGriffith https://gitlab.com/gitlab-org/gitlab-ce/issues/56961#note_136191131, some comments of @proglottis are also relevant: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/25687#note_148986469
With this Merge Request, you can put a template (with environment variables) of a Helm YAML values file (i.e. chart/auto_deploy_values_template.yaml
) in your Git repository and set the values of these environment variables in your GitLab project's Settings > CI/CD > Environment variables section (i.e. STORAGE_CLASS
CI variable). So your template file is version controlled and the values are externalized from your code (i.e. 12 factor guidelines).
Or you can use a AUTO_DEPLOY_VALUES_YAML
CI variable if you don't want to version controlled a template values file.
Here, a bit of documentation to explain what you can do...
Set additional Helm chart values in a CI variable
Go to your GitLab project's Settings > CI/CD, then expand the section called Environment variables.
You can set your additional Helm chart values in a CI variable, like this:
Variable | Value |
---|---|
AUTO_DEPLOY_VALUES_YAML | postgresql: enabled: true image: tag: $${POSTGRES_VERSION:-9.6} postgresqlUsername: $$POSTGRES_USER postgresqlPassword: $$POSTGRES_PASSWORD postgresqlDatabase: $$POSTGRES_DB |
You are able to use other variables inside your variable definition (but you should escape them with $$
).
Customize additional Helm chart values file path
By default, your additional Helm chart values can be stored (or will be generated if AUTO_DEPLOY_VALUES_YAML
is present) in the chart/auto_deploy_values.yaml
path of your project.
If for some reason you want to change it.
Go to your GitLab project's Settings > CI / CD, then expand the section called Environment variables, and add CI variable like this:
Variable | Value |
---|---|
AUTO_DEPLOY_VALUES_PATH | chart/custom_values.yaml |
Overwrite Helm chart default values file path
NOTES: This paragraph is not very important, but I keep it, just in case:
Set the CI variable AUTO_DEPLOY_VALUES_PATH
with this value: chart/values.yaml
.
Be careful, it'll overwrite the values.yaml
file of your chart, so you need to provide all default values.
Go to your GitLab project's Settings > CI / CD, then expand the section
called Environment variables.
And set the whole values.yaml
content inside the AUTO_DEPLOY_VALUES_YAML
CI variable.
AUTO_DEPLOY_VALUES_YAML
CI variable
If you don't set the In your Git repository, you can add a chart/auto_deploy_values_template.yaml
file and add your additional values content, like this:
postgresql:
enabled: $POSTGRES_ENABLED
image:
tag: 9.6
postgresqlUsername: $POSTGRES_USER
postgresqlPassword: $POSTGRES_PASSWORD
postgresqlDatabase: $POSTGRES_DB
persistence:
storage:
storageClass: $STORAGE_CLASS
foo: ${BAR:-my_default_value}
Go to your GitLab project's Settings > CI / CD, then expand the section called Environment variables, and add CI variable(s) like this:
Variable | Value |
---|---|
STORAGE_CLASS | nfs |
BAR | my_value |
Overwrite Helm chart template file path for customized values
By default, Auto Deploy will use the template file, for additional Helm chart values, stored in the chart/auto_deploy_values_template.yaml
path of your project.
If for some reason you want to change it.
Go to your GitLab project's Settings > CI / CD, then expand the section called Environment variables, and add CI variable like this:
Variable | Value |
---|---|
AUTO_DEPLOY_VALUES_TEMPLATE_PATH | chart/custom_values_template.yaml |
What are the relevant issue numbers?
Does this MR meet the acceptance criteria?
-
Changelog entry added, if necessary -
Documentation created/updated via this MR -
Documentation reviewed by technical writer or follow-up review issue created -
Tests added for this feature/bug -
Tested in all supported browsers -
Conforms to the code review guidelines -
Conforms to the merge request performance guidelines -
Conforms to the style guides -
Conforms to the database guides -
Link to e2e tests MR added if this MR has Requires e2e tests label. See the Test Planning Process. -
Security reports checked/validated by reviewer