Pipeline:1st Stage Manual 2nd Stage Automatic

GitLab CI/CD
1

Problem to solve

In my pipeline I am struggling to apply the below logic:
Stage 1: 3 jobs that are manually triggered by user. Only one job is required to run and it is uncertain which job will run in stage 1.

Stage 2: After 1 job is run in stage 1, it should trigger another job in stage 2 to run automatically. I am unable to setup the above logic and the jobs in 2nd stage are always shown as blocked on pipeline.

Any help is much appreciated!

Configuration

stages:
  - build
  - test

job1:
  stage: build
  when: manual
  allow_failure: false
  script:
    - echo hello
  artifacts:
    paths:
      - artifacts/

job2:
  stage: build
  when: manual
  allow_failure: false
  script:
    - echo hello
  artifacts:
    paths:
      - artifacts/

job3:
  stage: build
  when: manual
  allow_failure: false
  script:
    - echo hello
  artifacts:
    paths:
      - artifacts/

job4:
  stage: test
  script:
    - echo hello
  needs:
    - job: job1
      optional: true
      artifacts: true
    - job: job2
      optional: true
      artifacts: true
    - job: job3
      optional: true
      artifacts: true

job5:
  stage: test
  script:
    - echo hello
  needs:
    - job: job4

job6:
  stage: test
  script:
    - echo hello
  needs:
    - job: job4

Versions

Please select whether options apply, and add the version information.

  • GitLab.com SaaS
  • Self-hosted Runners
2

This is currently not possible with needs/ dependencies as far as I know.
The easiest way would be to set Job4 to manual.

You could possibly build something using dotenv, but I’m not so sure myself.

3

Thanks. I am trying to work around this by inducing a variable in first stage/job which is also manual. I have added a global variable option like below but when it’s pushed, I can’t seem to see the defined variable as a user input on the manual job?

variables:
  BITS:
    value: "32"
    options:
      - "32"
      - "64"
    description: "32Bits or 64Bites build size. Defaults to 32Bits."
4

Correct me if I have misunderstood you.

variables:options cannot be defined at job level.

In your example, you also have it in the global context. However, the global context is before the job start. That’s why you don’t get a selection if you want to start the job manually.

This is not a solution, but a complete example of what you have sent:

variables:
  BITS:
    value: “32”
    options:
      - “32”
      - “64”
    description: “32Bits or 64Bites build size. Defaults to 32Bits.”

job1:
  stage: build
  when: manual
  script:
    - echo hello $BITS
  rules:
    - if: $CI_PIPELINE_SOURCE == “web”  # not a solution

Edit:

I had a look to see if I could find a solution with the pass of dotenv. Unfortunately, I don’t see any option. I’m afraid the last and really only way here (as of 2024) is to go via the REST API.

This is roughly what it would look like if you go via the REST API. The disadvantage here is that Job3 can always be triggered even though Job1 and Job2 have not started.

job1:
  stage: build
  when: manual
  script:
    - echo hello Job1
  after_script:
    - echo "trigger job3"

job2:
  stage: build
  when: manual
  script:
    - echo Hello Job2
  after_script:
    - echo "trigger job3"

job3:
  stage: test
  needs: []
  script:
    - echo hello world
  when: manual

Apart from your previous approach. I would suggest that you do it differently if the requirement allows it.

You only take out the jobs that are relevant. This means that the job in Test Stage does not have to wait for all jobs but only one.
The disadvantage here is that you always have a default case, which may not always be the best choice.

variables:
  STARTER: 
    value: "job1"
    options:
      - "job1"
      - "job2"
    description: "Pick your job."

job1:
  stage: build
  when: manual
  script:
    - echo hello Job1
  rules:
    - if: $STARTER == "job1"

job2:
  stage: build
  when: manual
  script:
    - echo Hello Job2
  rules:
    - if: $STARTER == "job2"

job3:
  stage: test
  script:
    - echo hello world

I have not specified rules:$CI_PIPELINE_SOURCE in this example. Feel free to add it yourself if you need it.