Allow an arbitrary number of jobs from a list of jobs to be required when using the needs: keyword

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Proposal

Currently, the needs: keyword has an array of jobs as input, and every job in that array is required to finish before the job using the keyword starts. It is however currently not possible to specify needs: [job1, job2, job3] and only requiring at least one of the jobs to succeed, regardless of which one it is.

A new attribute for the needs: keyword called required could modify that behavior. Possible values would be all and any, with all being the default and working just as the keyword currently works:

current_syntax:
  stage: test
  needs: ["linux:build", "mac:build"]
  script: echo "Running once linux:build and mac:build have run (because `required` is implicitely set to `all`)"

proposed_syntax_all:
  stage: test
  needs:
    jobs: ["linux:build", "mac:build"]
    required: all
  script: echo "Running once linux:build and mac:build have run (because `required` is explicitely set to `all`)"

New functionality would then be possible using this syntax:

proposed_syntax_any:
  stage: test
  needs:
    jobs: ["linux:build", "mac:build"]
    required: any
  script: echo "Running once either linux:build or mac:build have run (because `required` is explicitely set to `any`)"

This is a non-exclusive or, any meaning "at least 1".

Instead of just allowing all or any as values for required, it would also be possible to allow any integer between 1 and the number of jobs n. all would be a shorthand for n, whereas any would be a shorthand for 1 – but users could specify even more flexible conditions if needed.

Related issues

Implementing this would likely cover the existing proposal 'needs:' with logical OR. Both this proposal and Backend: Additional inputs for `job:when:` to a... (#365851) were thought of as possible solutions to that issue with broader applicability.

Customer demand

A need for this kind of flexibility came up in the following internal tickets from customers:

Edited by 🤖 GitLab Bot 🤖