Using variable in environment name

I have the following configuration:

      script: ...
        name: ci/$NAMESPACE

According to documentation I do not see a limitation:

But when running it shows ci/$CI_COMMIT_REF_SLUG in the jobs and environment view. While I expect e.g. ‘ci/master’. The script itself seems to work fine, but I can not make distinction between different runs on different branches. Anyone an idea why this occurs?

version: GitLab Community Edition [13.8.2]

I think that’s an error. Here’s a quick and dirty testing repository that demonstrates the issue:
Using variables defined even on top of .gitlab-ci.yml do not work.

However the sample from in the documentation does work:

        name: env4/$CI_COMMIT_REF_NAME

Thanks for confirming that it is an error. How to proceed with this? Would like to have it fixed or have a workaround :slight_smile:

I wonder whether it’s because you are using $CI_COMMIT_REF_NAME rather than $CI_COMMIT_REF_SLUG which escapes the text in the commit name, and is safe to use in URLs?



If I do it with an indirect reference through variables as in my example both does not work.

Perhaps I’ve misunderstood your question? This is how I do a similar thing:

    stage: deploy
        - ...
        - if: '$CI_COMMIT_BRANCH == "master"'
          when: never
        - when: always
            - public
        name: ci/$CI_COMMIT_BRANCH
        url: ...
        auto_stop_in: ...

Does that help?


1 Like

Nope :slight_smile: I want to use a variable in Reason is that I want to trigger the pipeline and give as variable input the environment I want to create and the default must be the branch name itself.

I think the config above does set the name with a variable?

Yes, but CI_COMMIT_BRANCH is a predefined variable which I can not provide during start of the pipeline. The example I provided is exactly what I need.

Sorry, @dkwakkel I’m obviously very confused. What’s the reason for giving CI_COMMIT_REF_SLUG an alias? Normally we would just use those variables as they are in the CI configs?

See my comment above:

Right, apologies. I suspect your problem stems from this issue which is unfortunately still open :frowning:


Thanks Sarah!