Reputation: 2587
I have one action (a yaml
file) for deploying a docker image to Google Cloud Run.
I would like to receive Slack or Email messages informing the build and push results.
How could the message action be triggered after build action is completed?
Is it possible to get the result of the build action?
Upvotes: 151
Views: 139780
Reputation: 11640
The best method i've found for reusable workflows in the same repository is https://docs.github.com/en/actions/using-workflows/reusing-workflows
In the workflow you want to re-use (let's call it wf1
):
# wf1.yml
on:
workflow_call:
In the workflow you want to call wf1
from (let's call this wf2
)
# wf2.yml
jobs:
call-wf1:
uses: ./.github/workflows/wf1.yml
secrets: inherit
In order to get data from one workflow to another, check out https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-outputs-from-a-reusable-workflow.
First, set up your reusable workflow to output the data:
name: Reusable workflow
on:
workflow_call:
# Map the workflow outputs to job outputs
outputs:
firstword:
description: "The first output string"
value: ${{ jobs.example_job.outputs.output1 }}
secondword:
description: "The second output string"
value: ${{ jobs.example_job.outputs.output2 }}
jobs:
example_job:
name: Generate output
runs-on: ubuntu-latest
# Map the job outputs to step outputs
outputs:
output1: ${{ steps.step1.outputs.firstword }}
output2: ${{ steps.step2.outputs.secondword }}
steps:
- id: step1
run: echo "::set-output name=firstword::hello"
- id: step2
run: echo "::set-output name=secondword::world"
Now use it in the calling workflow:
name: Call a reusable workflow and use its outputs
on:
workflow_dispatch:
jobs:
job1:
# local repo
# uses: ./.github/workflows/called-workflow.yml@v1
# other repo
uses: octo-org/example-repo/.github/workflows/called-workflow.yml@v1
job2:
runs-on: ubuntu-latest
needs: job1
steps:
- run: echo ${{ needs.job1.outputs.firstword }} ${{ needs.job1.outputs.secondword }}
Upvotes: 26
Reputation: 5931
First, you are mixing terms here. According to GitHub Actions documentation a single YAML file is called a workflow (not an action) and consists of jobs. Jobs contain a sequence of steps (including actions) that are executed one after another. A particular workflow execution is called a run. Having that in mind lets go the questions.
How could the message workflow be triggered after build workflow is completed?
You can use GitHub API to trigger a webhook event called repository_dispatch
(only for the base branch) or workflow_dispatch
. This can be easily done using a dedicated Repository Dispach action in your build workflow.
Is it possible to get the result of the build workflow?
Yes, the result of the workflow run can be obtained using given GitHub API
But if you only want to send the build result notification of the currently executed workflow you don't need to create a separate workflow and trigger it from the parent. You can use dedicated Slack actions or e-mail actions.
Upvotes: 15
Reputation: 14419
There are 2 options of doing this:
workflow.yml
together with the needs
keywordnotify.yml
workflow that uses the workflow_run
event as a trigger1. Same workflow, separate job with needs
keyword
In your workflow.yml
file you simply define two jobs like this (leveraging the needs: build
configuration in the second job):
name: CI build and notify
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Deploy Docker image to Google Cloud Run
run: ...
notify:
needs: build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Notify Slack and send eMail
run: ...
As the docs state, the second notify
job will only start if the first build
job succeeded:
Identifies any jobs that must complete successfully before this job will run.
Here's a screenshot of how this approach can look like practically from my own project (I have a second publish-snapshot
job instead of your notify
job - but the concept stays the same):
There's also a way to always let the notify
job run, even if the build
job failed. You have to enhance the needs
with a if: always()
configuration then.
2. Separate workflow, using the workflow_run
event as a trigger
Using the workflow_run
event as a trigger we end up having 2 separate GitHub Actions workflow yaml files:
build.yml
name: CI build
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Deploy Docker image to Google Cloud Run
run: ...
notify.yml
name: CI notify
# Only trigger, when the build workflow succeeded
on:
workflow_run:
workflows: ["CI build"]
types:
- completed
jobs:
notify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Notify Slack and send eMail
run: ...
A crucial point here is that the name: CI build
definition of the first yaml file must exactly match the workflow_run: workflows: ["CI build"]
definition in the second yaml file. Another point is that this approach needs to be done on the default branch (which is mostly main
or master
) as the docs state:
Note: This event will only trigger a workflow run if the workflow file is on the default branch.
Here's also a full example project using the 1st option if you're interested.
Upvotes: 286
Reputation: 151
you can try in step 2 the following directive:
needs: step-1-job-name
just after job name
Upvotes: 11
Reputation: 1323045
How could the message action be triggered after build action is completed?
This should now (August 2020) be possible with "GitHub Actions improvements for fork and pull request workflows"
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 theworkflow_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 web hook.
Upvotes: 3