Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to use the GitHub Actions `workflow_run` event?

Tags:

Another frequently-requested feature for Actions is a way to trigger one workflow based on the completion of another workflow. For example, you may want to take the results of a CI workflow and run some further analysis.

The new workflow_run event enables you to trigger a new workflow when one or more workflows are requested or completed. Runs triggered by the workflow_run event always use the default branch for the repository, and have access to a read/write token as well as secrets. As an example, as a maintainer you could set up a workflow that takes the artifacts generated by the pull request workflow, do some analysis, and post comments back to the pull request. This event is also available as a webhook and works all repos.

This is quoted from Github's blog.

Could anybody tell me how to implement the example proposed using the new event workflow_run? The documentation only provide a very simple example:

on:   workflow_run:     workflows: ["Run Tests"]     branches: [main]     types:        - completed       - requested 

I would be very glad if someone can teach me how to achieve the example.

like image 354
BobAnkh Avatar asked Aug 10 '20 16:08

BobAnkh


People also ask

How do I trigger a GitHub Action with an HTTP request?

These three steps are given below. Create github action. Generate a personal access token. Create a http request.

What is GitHub Actions and how do you use it?

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.


1 Answers

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:

--- 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:

Screenshot of workflows screen

As you can also see, the branch does not appear for the "Test" workflow.

This is because, (quoting from the manual):

Screenshot of caveat in the manual

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

This means that the "Test" workflow will run on/with the code from the default branch (usually main or master).

There is a workaround for this...

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:           ref: ${{ github.event.workflow_run.head_branch }}       - run: git branch       - run: env 
like image 83
Potherca Avatar answered Oct 11 '22 15:10

Potherca