Rename "secret variables"
We have something called "secret variables" which are named that way because the variables and their values are not in source control, thus hidden from viewers. But they're not exactly "secret", and that name isn't really intuitive. We should change it to something better that more accurately reflects what they are.
In some places we call them "project variables and group variables", but that's a bit of a mouth full. Other vendors call them "environment variables", and that's the leading candidate. But "environment variables" is still a bit tricky because there are multiple environments we're talking about. Not only do we have a feature called environments (staging, production, etc.), but there's also the difference between the environment that the job runs in during CI/CD, and the environment your app runs in (in Docker, for example). To make it more complicated, there are also variables we pass to Helm with Auto DevOps.
A simple answer might be to make all environment variables be available in all of these places, automatically passing all variables to Helm, and then passing all variables on to K8s for inclusion in the Docker image. But, do you really want your K8s deploy credentials to be available to your app at run time, for example?
A different tactic could be to use conventions like prefixing variables with
K8S_ if you want them to be passed to Kubernetes.
Or have a dropdown with scope choices in the GitLab UI to explicitly choose where variables should be made available.
Still, it might be reasonable to call these environment variables, and then leave the challenge of deciding scope of these variables to a separate issue.
Links / references
What is it? Why should someone use this feature? What is the underlying (business) problem? How do you use this feature?
Who is this for? Provide one or more use cases.
Make sure these are completed before closing the issue, with a link to the relevant commit.