Same steps for multiple named environments with GitLab CI

Question

Is there a way to configure multiple specifically-named environments (specifically, test, stage, and prod)?

In their documentation (https://docs.gitlab.com/ce/ci/environments.html) they talk about dynamically-created environments, but they are all commit based.

My build steps are the same for all of them, save for swapping out the slug:

deploy_to_test:
    environment:
         name: test
         url: ${CI_ENVIRONMENT_SLUG}.mydomain.com
    scripts:
         - deploy ${CI_ENVIRONMENT_SLUG}

deploy_to_stage:
    environment:
         name: stage
         url: ${CI_ENVIRONMENT_SLUG}.mydomain.com
    scripts:
         - deploy ${CI_ENVIRONMENT_SLUG}

 deploy_to_prod:
    environment:
         name: prod
         url: ${CI_ENVIRONMENT_SLUG}.mydomain.com
    scripts:
         - deploy ${CI_ENVIRONMENT_SLUG}

Is there any way to compress this down into one set of instructions? Something like:

deploy:
    environment:
         url: ${CI_ENVIRONMENT_SLUG}.mydomain.com
    scripts:
         - deploy ${CI_ENVIRONMENT_SLUG}

Answer 1

Just in case: Gitlab offers (since 11.3) an extends keyword, which can be used to "templates" yaml entries (so far as I understand it):

See the official doc

Answer 2

Yes, you can use anchors. If I follow the documentation properly, you would rewrite it using a hidden key .XX and then apply it with <<: *X.

For example this to define the key:

.job_template: &deploy_definition
    environment:
         url: ${CI_ENVIRONMENT_SLUG}.mydomain.com
    scripts:
         - deploy ${CI_ENVIRONMENT_SLUG}

And then all blocks can be writen using <<: *job_template. I assume environment will merge the name with the predefined URL.

deploy_to_test:
   <<: *deploy_definition
    environment:
         name: test

deploy_to_stage:
   <<: *deploy_definition
    environment:
         name: stage

 deploy_to_prod:
   <<: *deploy_definition
    environment:
         name: prod

---

Full docs section from the link above:

YAML has a handy feature called 'anchors', which lets you easily duplicate content across your document. Anchors can be used to duplicate/inherit properties, and is a perfect example to be used with hidden keys to provide templates for your jobs.

The following example uses anchors and map merging. It will create two jobs, test1 and test2, that will inherit the parameters of .job_template, each having their own custom script defined:

.job_template: &job_definition  # Hidden key that defines an anchor named 'job_definition'
  image: ruby:2.1
  services:
    - postgres
    - redis

test1:
  <<: *job_definition           # Merge the contents of the 'job_definition' alias
  script:
    - test1 project

test2:
  <<: *job_definition           # Merge the contents of the 'job_definition' alias
  script:
    - test2 project

& sets up the name of the anchor (job_definition), << means "merge the given hash into the current one", and * includes the named anchor (job_definition again). The expanded version looks like this:

.job_template:
  image: ruby:2.1
  services:
    - postgres
    - redis

test1:
  image: ruby:2.1
  services:
    - postgres
    - redis
  script:
    - test1 project

test2:
  image: ruby:2.1
  services:
    - postgres
    - redis
  script:
    - test2 project