Is your branch master or main?

It might be silly in the future but as for October 2020 just keep in mind that the default GitHub branch has been renamed from master to main (source).

So if you are copypasting actions from elsewhere, make sure that you are targeting the correct branch (for new repos this means most of the time to replace master with main in the .yml workflow files).

If you are targeting the wrong branch, the name of the action will appear on GitHub but no actions will actually run.

A recent change (~24 hours) has been rolled back now.

Feel free to ping again if you're still experiencing issues with future workflow runs, starting now.

@sblantipodi,

Is the workflow “GitHub Linux Release” existing on the master or default branch?
To trigger a workflow runs on the workflow_run event, the workflow file should exist on the master or default branch.

Here is a recent reported similar topic as reference:

Workflow runs not starting after previous workflow completes GitHub Actions

@andrewconnell, There are few points maybe can explain the problems:

The workflow runs on workflow_run event must exist on the master or default branch. And this workflow will only run on the master or default branch, regardless of whether it is triggered by a workflow run on other branches or not.

On the Actions page of a repository, under the “All workflows”, generally the following workflows are listed:

The workflow files exist on any branches, and the workflows have been triggered …

In addition, if you want the workflow “GitHub Linux Release” is triggered after the workflow “CreateRelease” completed, you should only use the type “completed”.

If the problem still exists, please share your repository with us (if possible), so that we can check more detailed configurations related to the workflows to analyze the root cause.

Annoyingly, this was due to using apostrophes in the workflow name in workflows: ["upload"]:

not working:

name: archive

on:
  workflow_dispatch:
  workflow_run:
    workflows: ["upload"]   <- issue here
    types:
      - completed

working:

name: archive

on:
  workflow_dispatch:
  workflow_run:
    workflows: [upload]
    types:
      - completed

https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run

The workflow_run event only works on the default branch.

instead of using workflow_run, look at using reusable workflows. Then in your code quality workflow, if everything works there, you would call a reusable workflow to do the testing.

@andrewconnell,

There are few points maybe can explain the problems:

1. The workflow runs on workflow_run event must exist on the master or default branch. And this workflow will only run on the master or default branch, regardless of whether it is triggered by a workflow run on other branches or not.

2. On the Actions page of a repository, under the “All workflows”, generally the following workflows are listed:

   • The workflow files exist on any branches, and the workflows have been triggered at least once.

   • The workflow files exist on the master or default branch, even if the workflows are never triggered.

   • For some events, especially the workflow_run event, if the workflow file does not exist on the master or default branch, this workflow will not be listed under the “All workflows”, even if the workflow file exists on other branches. This workflow also will be never triggered.

@cuporter,

Currently, there are only the two types requested and completed for the workflow_run event.

As a workaround, you can use the expression “github.event.workflow_run.conclusion” to get the result of the previous workflow run, and use the job 's if conditional to skip all the job in the current workflow run when the previous workflow run is not success.

name: Production deploy
on:
  workflow_run:
    workflows: ["Stage deploy"]
    types:
      - completed
jobs:

job1:

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

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

jobN:

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

Of course, you also can directly report a feature request that add more types for the workflow_run event (such as success and failure) here.
That will allow you to directly interact with the appropriate engineering team, and make it more convenient for the engineering team to collect and categorize your suggestions.

To get the example to work (i.e. to have one workflow wait for another to complete) you need two files. Both files live in the .github/workflows folder of a repository.

The first file would be set up as usual. This file will be triggered by whatever event(s) are set in the on section:

---
name: Preflight

on:
  - pull_request
  - push

jobs:
  preflight-job:
    name: Preflight Step
    runs-on: ubuntu-latest
    steps:
      - run: env

The second file states that it should only trigger on the workflow_run event for any workflows with the name Preflight and must be on your repository's default branch, usually main or master:

---
name: Test

on:
  workflow_run:
    workflows:
      - Preflight
    types:
      - completed

jobs:
  test-job:
    name: Test Step
    runs-on: ubuntu-latest
    steps:
      - run: env

This more-or-less the same as the example from the GitHub Actions manual.

As you can see on the actions page of my example repo, the Preflight workflow will run first. After it has completed, the Test workflow will be triggered:

When you try this out, you will find that the Test workflow always runs the code and workflow configuration on your default branch, usually main or master.

This is because, (quoting from the manual):

This event will only trigger a workflow run if the workflow file is on the default branch.

This means you'll need to develop workflows triggered by workflow_run on your default branch, which is a little unfortunate.

This also means that if you need the "Test" workflow to run against the code of your branch or pull request, then you'll need to do more work as described below:

Every actions is run with a set of contexts. The github context holds information about the event that triggered the workflow. This includes the branch that the event was originally triggered from/for: github.event.workflow_run.head_branch.

This can be used to check out the origination branch in the action, using the actions/checkout action provided by GitHub.

To do this, the Yaml would be:

---
name: Test

on:
  workflow_run:
    workflows:
      - Preflight
    types:
      - completed

jobs:
  test-job:
    name: Test Step
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          repository: '${{ github.event.workflow_run.head_repository.full_name }}'
          ref: ${{ github.event.workflow_run.head_branch }}
      - run: git branch
      - run: env

Thank you for reporting the issue with scheduled workflows not triggering. We identified a related change from last week that was rolled back today. Any commit pushed to the default branch will resync the impacted scheduled workflows and resolve any scheduling issues you may be experiencing. If you continue to experience issues with syncing schedules, please reply with a comment including the following:

1. Impacted repository
2. Workflow path and name
3. Cron syntax in the workflow

Note: Schedules that run during periods of high load (e.g., midnight UTC) may be delayed or, if load is sufficiently high, potentially dropped. Please see our docs for further information.

It’s a bug with GitHub, I just confirmed. I changed the name of the files and the name of the workflow and now it’s showing for me.

Some workflows, such as those, based on workflow_dispatch event, the workflow will not even show until the code is on the main (or default branch).

The good news is, once you do merge your feature to main, you may keep on working on the feature branch. From then on, you will have the option to choose which branch you want to run the workflow on , like in the picture.

Thanks to the GH support, the answer is here : Workflow_run not working as expected - #4 by brightran

We can access the original ref with

github.event.workflow_run.head_branch

Problem solved !