CI rules based on another job's results

Problem to solve

This proposal would solve multiple issue, but I'll describe the two main ones I have:

Parallel pipelines

Let's assume the following pipeline:

Stage build:

build.A
build.B

Stage deploy

deploy.A (needs build.B)
deploy.B (needs build.B)

If build.B succeeds, and build.A fails, a user might want deploy.B to not run, but deploy.A.

Conditional manual execution

Let's assume a three stages pipeline (build, test, stage). I want :

stage to run if test succeeds.
stage to be runnable manually if testfails.

I have not found any way to do this. Right now, manual is mutually exclusive with on_failure.

Intended users

Devon (DevOps Engineer)

Further details

Proposal

Allow rules to filter on the result of a named job. I suggest we add this though additional keywords for the rules:

success
failure
skipped

I don't really see how this can be implemented through if.

In our first case, we could indicate that deploy.A is to be run only if build.A was successful.

deploy.A:
  rules:
    - success: "build.A"
      when: always
    - when: never

For our second case, we could allow stage to go trough automatically if test worked, but require manual intervention otherwise:

stage:
  rules:
    - failure: "test"
      when: manual
    - when: on_success

Another, maybe simpler approach, would be to expose previous jobs' result through variables. It would then be possible to use those in if: rules. Thos might look like:

stage:
  rules:
    - if: '$JOB_TEST_STATUS == "failure"'
      when: manual
    - when: on_success

Or possibly:

stage:
  rules:
    - if: '$JOB_STATUS["test"] == "failure"'
      when: manual
    - when: on_success

Permissions and Security

This would integrate within the existing CI framework, and I believe would not add any security implication.

Documentation

We'd need to update the .gitlab-ci.yaml syntax documentation.

Testing

Since it's only added syntax, there is no risk of breaking existing pipelines. We only need to test the added features by adding a few test pipelines.