<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=337740) </details> <!--IssueSummary end--> <!-- This issue template can be used a great starting point for feature requests. The last section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab. --> ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> When defining a description for a variable in CI config, the description text can include another variable as long as this is defined at a higher layer (such as in an pre-included file, or at the project/group/instance levels) ### Problem to solve <!-- What is the user problem you are trying to solve with this issue? --> A user may want to leverage the pre-filled variables feature but also have control over the description text displayed for it on the form in a more dynamic way. Instead of editing the CI config file for each description change, they may want to define the description at the project/group level through a variable and use that to control the displayed text. For example the description may include an advise of valid option values that may change frequently over time, and its easier to change a project-level variable that lists the options (or reuse one), than edit the CI config each time. ### Proposal <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. --> Allow the following forms to work with substitution: ``` variables: FOO: value: description: "Some text with ${PROJECT_LEVEL_VAR_NAME} allowed" BAR: value: description: $GROUP_LEVEL_VAR_NAME ```