GitlabCI - define a job dependency on some other conditional job

in my case I want to run job smoke-test only when the job deploy finished sucessfully. There is a keyword needs, that should do exactly that.

However in docs there is also written:

In GitLab 13.9 and older, if needs: refers to a job that might not be added to a pipeline because of only, except, or rules, the pipeline might fail to create.

And that is exactly my case (pipeline does not even start, because the deploy job does not exist). The deploy job is conditional using a very complex rules condition:

  rules:
    - if: $CI_KUBERNETES_DEPLOYMENT_ENABLED != "true"
      when: never
    - if: $STAGING_CHART_DIRECTORY == ""
      when: never
    - if: $STAGING_NAMESPACE == ""
      when: never
    - if: $CI_REVIEW_DEPLOYMENT_ENABLED != "true" && $CI_MERGE_REQUEST_ID
      when: never
    - if: $CI_MERGE_REQUEST_ID && $CI_COMMIT_REF_PROTECTED == "true"
      when: never
    - when: on_success

I don't want to define duplicit rules condition also for the smoke-test job - it would be pain to keep consistency.

How to just simply say "run smoke-test job only when deploy job finished sucessfully" in this case? What is the best practice here?

• maybe set some environment variable in the deploy job DEPLOY_JOB_SUCCESS=true and depend on it in smoke-test job
• or use some yaml anchor (however in this case the pipeline definitions are not within one yaml file)
• or something else?

I will be thankful for any kind of a hint :)

// gitlab version: GitLab Enterprise Edition 14.4.2-ee

It is not exactly what you are looking for, but there is a way of not maintaining the rules twice. Actually 3 ways :)

1. using extends aka inheritance - you define the rules ones and extend from it

.rules:
   rules:
     - if: ....

deploy:
   extends:
     - .rules

smoke-test:
   extends:
     - .rules

2. references - aka composition - https://docs.gitlab.com/ee/ci/yaml/yaml_optimization.html#reference-tags

deploy:
   rules:
     - if: ....

smoke-test:
   rules:
     - !reference ['deploy', rules]

3. yaml anchors

Those 3 ways allow you to reuse your rules easily, and should help you regarding your issue