Can we use a stage name instead of a job name to make a job dependent on another job in .gitlab-ci.yml file?

Question

Is it possible to use a stage name instead of the job name to make a job dependent on another job?

stages:
  - build
  - deploy
  - tests

build-job:
  stage: build

deploy-feature:
  stage: deploy
  except:
    - master
  when: manual

deploy-prod:
  stage: deploy
  only:
    - master
  when: manual

test-cases:
  stage: tests
  dependencies: deploy-feature

That is, instead of using "deploy-feature" can I by any chance use "deploy" to make the test-cases job depend on both deploy-feature and deploy-prod jobs? I know that it doesn't work in dependencies but is there anything else with which it might work?

P.S. My motive is to run my test-cases job only after any one of the deploy-feature or deploy-prod jobs is successful. As currently, my "deploy" jobs are manual and the "test" job isn't so my "test-cases" job gets executed beforehand. I can do a "when: manual" in my test-cases job as well and can run it manually after my deploy job but to me, that feels like a workaround and not a solution. And I have around 17 "tests" jobs so having 2 different jobs for every test-case job is also not a feasible idea.

Edit: Although I have accepted an answer, even then if anyone has something more to add or any different solution please do share.

Answer 1

As of GitLab 14.3, no, you can't use a Stage in any of the keywords where you can use a Job name, however it sounds like your main issue is that your test-cases job starts before either deploy-feature or deploy-prod finish. This is because manual jobs are not treated the same as jobs in the Pending state, so jobs in stages after Manual Jobs can start as soon as the stage is reached, runners are available, or needs are met.

You can control this behavior with the needs keyword.

stages:
  - build
  - deploy
  - tests

build-job:
  stage: build

deploy-feature:
  stage: deploy
  rules:
    - if: $CI_COMMIT_REF_NAME == 'main'
      when: never
  when: manual

deploy-prod:
  stage: deploy
  rules:
    - if: $CI_COMMIT_REF_NAME == 'main'
      when: manual

feature-test-cases:
  stage: tests
  rules:
    - if: $CI_COMMIT_REF_NAME == 'main'
      when: never
  needs: ['deploy-feature']

prod-test-cases:
  stage: tests
  rules:
    - if: $CI_COMMIT_REF_NAME == 'main'
      when: manual
  needs: ['deploy-prod']

This is a little different from the example in your question since we split up the test-cases job into two, one for a 'feature' branch and another for 'main'. It is possible to use a single test-cases job and have it "need" both deploy jobs, but both would have to complete, which isn't possible given our rule set (which is based on your use of only and except: we can't have a branch not be main and be main in the same Pipeline).

One thing I changed is swap only and except for rules. Rules gives us more flexibility since we can define actual if conditionals along with OR's and AND's, and we can define multiple conditions with different outcomes. For example, one outcome might be when: always, another when: manual, and the last when: never all in the same job. Also note, according to the docs:

*only* and *except* are not being actively developed. *rules* is the preferred keyword to control when to add jobs to pipelines.

When using rules like this, not only does it control when or why a job will be manual or not, it also controls which jobs are even in the pipeline instance at all. For example, for the deploy stage, since we can't have main and "not-main" in one pipeline, only one deploy job will ever be in a single pipeline instance. Therefore, if our test-cases job "needed" both deploy jobs, it would fail during runtime since it can't find one or the other deploy job. So we have to have one test-case job for both pipeline paths.