Wait for at least one succeeded job before going to next step

GitLab CI/CD
1

Hello,

I would like a way to go only on step 2 only when at least one job has been selected in step1. I tried using rules but it doesn’t work. Is there a way do do that ?

stages:
  - step1
  - step2

variables:
  STEP1: "false"

.job-manual-template:
  stage: step1
  variables:
    STEP1: "true"
  script:
    - echo STEP1="true" >> variables.env
  artifacts:
    reports:
      dotenv: variables.env
  when: manual

job1-manual:
  extends: .job-manual-template

job2-manual:
  extends: .job-manual-template

job3-manual:
  extends: .job-manual-template

wait-at-least-one:
  stage: step2
  script:
    - echo $STEP1
  rules:
    - if: $STEP1 == "true"
      when: on_success
    - if: $STEP1 == "false"
      when: manual

Thanks,

Chris.

2

Since all your steps are identical, I can’t figure out what you’re really trying to do. Somebody asked this on StackOverflow, though. Does this answer your question?

3

It’s just an easy sample.
And no it doesn’t answer my question.

4

Yeah, but it’s too easy. Give us a real example of what you want to do. Technically, no, afaict you can’t make stage C depend on either A or B, but I’d be really shocked if I couldn’t make it happen anyway.
Say, run the Shell executor and put an IF/ELSE in it, or a Docker executor where the build command builds one of two different images.

Or, really grungy work-around, trigger a new pipeline whenever either precursor steps completes. I hate that, but it does work. See Why triggering manual job is not allowed? - #2 by mkoehl

5

Imagine that ‘Step1’ is a list of applications to deploy, and I choose the one I want to deploy.
And ‘Step 2’ is the job that allows to deploy only the selected applications.

I could use manual triggers with variables but I wanted to find another way to do it, more user-friendly.

6

dotenv doesn’t work with rules since rules are evaluated before the pipeline is started.

The issue with your approach is that job in step2 will be executed exactly once. And immediately after you manually run first job from step1. Since dependency condition would be met if you later run second job from step1 it won’t trigger another run of job in step2. So you will be able to deploy exactly single application in each pipeline. Yes, you could play around with retries and such, but why bother?

Easier approach would be to setup an actual deploy job for each application and it will deploy after you manually run it. I don’t see the benefit of having another job to tell another job what to deploy.