how do you use github.event.workflow_run.conclusion == 'success' when you have multiples workflows?

name: Production deploy
on:
  workflow_run:
    workflows: ["CI", "Linters"]
    types:
      - completed

@edudepetris I assume that both CI and Linters both trigger separate workflow_run events, i.e. you only see a single conclusion, from one of the parent workflows. You may want to verify this with e.g.

name: Production deploy
on:
  workflow_run:
    workflows: ["CI", "Linters"]
    types:
      - completed
jobs:
  test:
    name: Test
    runs-on: ubuntu-latest
    steps:
      - name: Print github context
        env:
          GITHUB_CONTEXT: ${{ toJSON(github) }}
        run: echo "$GITHUB_CONTEXT"

If I’m right, then it might not be possible to wait for both parent workflows to succeed and then run the production deployment, unless you let Linters trigger CI and then let CI trigger Production deploy…

@brightran your suggestion works great, however, it is not documented in the webhook events docs: https://docs.github.com/en/free-pro-team@latest/developers/webhooks-and-events/webhook-events-and-payloads#workflow_run

I wonder if this property is authoritative, or will be removed in the future?

How was this ever considered useful or fit for production use in it’s current form?
Triggering workflows on completion regardless of status is so naïve, it has no applicability in the real world

The workaround, aside from being ugly and error prone, still results in the workflow being triggered so you end up with hundreds of skipped runs when you look at the UI

this was frustrating me enough that I went ahead and created a new Action to deal with the shortcomings of workflow_run, namely:

The workflow_run event occurs when a workflow run is requested or completed, and allows you to execute a workflow based on the finished result of another workflow.

example

on:
workflow_run:
  workflows: [ test ]
  types: 
    - completed

However by itself, this doesn’t quite work as expected.

1. The completed type, does not indicate success, for that you’d have to include the following in each job of your workflow:

   if: ${{ github.event.workflow_run.conclusion == 'success' }}
   

2. If you’re depending on more than one workflow, then ANY of them completing, will trigger the event

   example

   name: deploy
   on:
   
   workflow_run:
   
   workflows: [ test, lint, compile ]
   
   types:
   
   - completed
   
   

   if your test workflow fails, but lint completed successfully, github.event.workflow_run.conclusion == 'success' will still be true

3. Your workflow will trigger as many times as you have workflow dependencies

   in the previous example, our deploy workflow, will run 3 times!

All this makes the workflow_run event fundamentally broken for any advanced usage, this Action aims to remedy that:

ahmadnassri/action-workflow-run-wait

wait for all `workflow_run` required workflows to be successful

An alternative to conditionals on conclusion.

Workflow run conclusion dispatch action - GitHub Marketplace

Workflow run to repository dispatch. Event is `${workflowName} - ${conclusion}`, client_payload is the workflow run payload

how to handle the case where the workflow having multiple triggers - workflow_run and workflow_dispatch? what will be the default value of workflow_run.conclusion then?

Yes it's working but jobs executed by workflow_run don't appear in status checks, is there any workaround?

This is a good feature request however. To add successful and perhaps failed types in the workflow_run event.

Why can you not have a standard dependency tree in which I have two workflows using two different computes that need to run in a separate workflow? Love what @pantelis-karamolegkos is saying here as well make a lot of sense.

why can we not have this wait till they are both complete or both successful I agree that that seems very odd but the need to have two jobs for example a docker image being built and the terraform resources are completed prior to executing this job rather than it defaulting to execute two jobs.

Sure can I look into GitHub check the history and if within the last 5 minutes it ran don't continue but why would that be something a user would need to do

success and error status types for all acting events (even push or merge, so you can run something if a push was rejected or a merge failed)

And, the best case scenario would be, inheritance (or import, however you want to call it) would be the best route. Import/inheritance should only be allowed from that local repository for security.

Say you have a bunch of actions that require you to checkout, set up python, set up node, yarn, poetry , and buildx/docker/qemu in some others, you should be able to do:

A special key like "inherits" or "import-jobs" or even *uses" at the job or steps level, with the format " {workflow}.{jobs|env|any-valid-key}.{steps|valid-subkey}.{job-id|deeper subkey}
Examples:
docker.jobs would be all of the jobs and subinformation of the jobs in the docker workflow.
docker.jobs.build_push would be the build_push job in the docker workflow
docker.jobs.build_push.steps.qemu
docker.jobs.build_push.runs-on

buildx.env.IMAGE_TAG would be the IMAGE_TAG variable set in env: in the buildx workflow

env: |
  IMAGE_TAG: ${{import("docker.env.IMAGE_TAG")

jobs:
  strategy:
      matrix:
        os: ${{ import("docker.jobs.matrix.os")}}
  setup:
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "hello world" 
      - uses: [ "environment.jobs.environment.steps.devops",  "linter.jobs.linting.steps.flake8" ]
      - run: |
          echo "All environment jobs and then linter jobs just ran in order, stopping execution if fail-fast is set in the matrix"

  qemu:
    - run: |
        echo "set up qemu"
    - uses: "docker.jobs.qemu" 
  import-jobs: [ "docker.jobs.buldx", "build.jobs", "release.jobs.upload.steps.push"  ] # import the entire buildx job from the docker workflow and run it as a job here, and then do the same with all of the jobs from the build workflow, and then just the push step from upload job in the release workflow - in the order they are specified (can also just be a string and just run one)
  finish:
    - run: |
      echo "all done" 

This sort of flexibility would make GitHub actions the most comprehensive and feature complete ci there is, and it would be the easiest to maintain your scripts and workflows because you D.R.Y

Anyone know if I could contribute something like this to GitHub? Where?