Multiple deployment jobs per environment

GitLab CI/CD
1

This is a question I’m having trouble answering after looking at some related issues/docs:

https://docs.gitlab.com/ee/ci/environments/deployment_safety.html


I felt like my exact situation didn’t come up in these issues even though the core idea is the same, so I must be missing some way of accomplishing what I want. I have a case where I’m deploying variations of the same backend service to the same environment in the same stage. So in the simplest case:

one:
  environment:
    name: dev
  stage: deploy
  script:
    - echo "service A: Variation 1"

two:
  environment:
    name: dev
  stage: deploy
  script:
    - echo "service A: Variable 2"

Gitlab CI considers these two deployment jobs to the same environment so the second one is always killed. I want these to both be able to run in the same pipeline, but if the same jobs are run in another pipeline I want the newer one to cancel the older one. I figured because these jobs have two different names they would be considered separate. So job “one” and “two” can both run, but a newer job “one” will cancel an older job “one” and similarly a newer job “two” will cancel an older job “two”.

I could define a resource_group but then I have to create one for the “one” job, the “two” job, and any other variations I create when the default job cancellation feature would work fine. Is there any other way I could make this work the way I expect?

1 Like
2

I just tried adding resource_group to my jobs (two different group names for the two jobs) and they are still considered the same deployment job and one fails because it is “older” than the other. How is this supposed to work? I thought I could have an environment and a resource_group at the same time.

3

There is a way around the one job per environment per stage limitation by appending to the environment, but it introduces other problems you need to solve for.

If you are extending a common job that uses CI_ENVIRONMENT_NAME which needs to be ‘dev’, you can call it with a parameter expansion - effectively the same as the dirname command (if you are using a slash).

Also in Settings > CI/CD > Variables if you previously had SERVICE_NAME (for example) scoped to ‘dev’ then you can glob in the search bar: when you type ‘dev/*’ an option to create wildcard will appear and it will now be available as needed.

.deploy_dev
  script:
    - echo "There is really only one ${CI_ENVIRONMENT_NAME%/*} environment"

one:
  environment:
    name: dev/one
  extends: .deploy_dev
  stage: deploy
  after_script:
    - echo "service ${SERVICE_NAME}: Variation 1"

two:
  environment:
    name: dev/two
  extends: .deploy_dev
  stage: deploy
  after_script:
    - echo "service ${SERVICE_NAME}: Variation 2"
2 Likes
4

danielk43, work like a charm! Thanks!

5

I have the same problem, and while @danielk43’s solution should work, while working on this I should Gitlab should have some conception of “platform” as well as environment.

I have an application being deployed to the web, android, and ios. We have a staging environment, in addition to production. This means we have two “environments”, but 3 “platforms”.

Just food for thought. The workaround described above is robust, and flexible enough to handle my use-case.