How to use the GitHub Actions `workflow_run` event? - github

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.

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:
As you can also see, the branch does not appear for the "Test" workflow.
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 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

Related

How to create a GitHub Actions workflow such that it always fail until a PR is approved?

Basically my workflow should trigger whenever there is an activity to PR branch and must fail until PR is approved.
To give more context below is my CI pipeline:
workflow 1 -> workflow 2-> workflow 3
workflow 1: Triggered when there is any pull request and uses madrapps/add-reviewers#v1 action to trigger automatic assignment of reviewers. If there is a new push to PR branch re-review is requested.
workflow 2 : Which is based on this question. This will sort of act like gate for workflow 3. This has to be triggered for every activity in PR branch and must fail if no approval is given.
workflow 3: This will do final build checks, formatting and auto merging PR requests. But this workflow is triggered only after workflow 2 is completed successfully.
Please find my implementation of workflow 2 below.
name: Review_submitted_check
on:
pull_request:
types:
branches:
- test_pr
pull_request_review:
types: [submitted]
branches: test_pr
jobs:
approval:
runs-on: ros-runner
steps:
- name: verify pass
if: github.event.review.state == 'approved'
run: exit 0
- name: verify fail
if: github.event.review.state != 'approved'
run: exit 1
The problem is two jobs are run for different trigger. One for approval submission and other for all PR activity. Since at a time only one of the job will succeed, I will always have one failed job.
Please advise on a better approach to this problem.

github action skips correctly but doesn't launch by the commit of another github action [duplicate]

Can I trigger a new workflow from another workflow?
I'm trying to run a workflow after the first workflow has pushed a new release and it seems to ignore it.
Found the answer here:
An action in a workflow run can't trigger a new workflow run. For example, if an action pushes code using the repository's GITHUB_TOKEN, a new workflow will not run even when the repository contains a workflow configured to run when push events occur.
EDIT:
The quote above might be confusing. When I add a Personal Access Token (PAT) to the checkout action with repo permissions granted (and not repository's GITHUB_TOKEN), the following commands DO trigger other workflows:
- name: Checkout Repo
uses: actions/checkout#v2
with:
token: ${{ secrets.PAT_TOKEN }}
(In my case, running semnatic-release after this checkout, which creates a new release with a new tag - did trigger another workflow that runs only if a tag was created)
As described here, you can trigger another workflow using the workflow_run event.
For example we could think of two workflow definitions like this (the only prerequisite is, that both reside in the same repository - but I'am sure, there's also an event for other repos as well):
release.yml
name: CI release
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Release artifact
run: ...
do-something-different.yml
name: Do anything after the release of the first workflow
on:
workflow_run:
workflows: ["CI release"]
types:
- completed
jobs:
notify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Do something
run: ...
A crucial point here is that the name: CI release definition of the first yaml file must exactly match the workflow_run: workflows: ["CI release"] 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.
If you don't want to use a general Personal Access Token (which has access to all of your repos), you can generate a dedicated SSH keypair for this purpose and add it to the repository as a Deploy Key. This is done as follows:
Generate an SSH keypair:
ssh-keygen -N "" -f deploy_key -C "github-actions"
Add the private key (generated file deploy_key) as an encryped secret, e.g. COMMIT_KEY to the GitHub project.
Add the public key (generated file deploy_key.pub) as a deploy key with write access to the GitHub project. Tick the Allow write access checkbox.
When checking out the source code in your workflow, add the SSH key:
- name: Checkout
uses: actions/checkout#v3
with:
ssh-key: "${{secrets.COMMIT_KEY}}"
Subsequent push actions in the same workflow will then trigger any configured GitHub workflow as if they were pushed manually.

How to trigger a workflow from another workflow using GitHub Actions?

I want to read version from a file and create tag as v11.0.5.1.aws using the workflow . Then I want to use that tag in the docker image.
For that, I have created a branch as devops.
First created a VERSION file as
1.1.3 20 Apr, 2022
Created a workflow as release-version.yml
name: Release Version
on:
push:
branches:
- devops
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#master
- name: Bump version and push tag
uses: melheffe/version_release_composer#master
env:
PREPEND: 'v'
APPEND: '.aws' # must include '.' or it will append without separation
DRAFT: 'false'
PRERELEASE: 'true'
TOKEN: ${{ secrets.AUTH_TOKEN }}
TRIGGER: ${{ github.event.pull_request.base.ref }} # can use the triggering branch or define a fixed one like this: 'master'
REPO_OWNER: rohit
VERSION_FILE_NAME: 'VERSION'
Then created another workflow as ci.yml which will get tag from release-version workflow
name: CI
# Only trigger, when the build workflow succeeded
on:
workflow_run:
workflows: ["Release Version"]
types:
- completed
jobs:
# This workflow contains a single job called "build"
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
DeployDev:
# Steps represent a sequence of tasks that will be executed as part of the job
name: Deploy to Dev
needs: [Build]
runs-on: ubuntu-latest
environment:
name: Dev
steps:
- uses: actions/checkout#v2
with:
token: ${{ secrets.AUTH_TOKEN }}
- name: Build, tag, and push image to Amazon ECR
id: build-image
#env:
# IMAGE_TAG: ${{ github.sha }}
run: |
# Build a docker container and push it to ECR so that it can
# be deployed to ECS.
echo "$GITHUB_REF_NAME"
docker build -t ${{secrets.ECR_REPO_URI}}/${{secrets.REPO_NAME}}:$GITHUB_REF_NAME .
docker push ${{secrets.ECR_REPO_URI}}/${{secrets.REPO_NAME}}:$GITHUB_REF_NAME
I'm able to trigger release version workflow after making changes on devops branch but ci workflow is not getting triggered after triggering the release-version.
Any suggestion will be helpful for me.
If the workflow_run trigger isn't working as expected, there are two other ways to achieve what you want (triggering a workflow from another workflow, sending an input parameter from the first one to use in the second one).
The workflow_dispatch event.
The repository_dispatch event.
The documentation is very good about how to use them, but I'll add here some references that can help as well:
Triggering Github Action using a POST request (Github REST API)
How to trigger a workflow_dispatch from Github API?
Triggering GitHub workflow using gh CLI
As you can see, you can trigger those events using directly the Github API in a step (with a CURL request) or using some actions from the Github Marketplace that perform the same operation.
The answer below also explains the difference between both events (as they are similar, and CURL payload differences may be confusing)
Correct request with client-payload to run workflow_dispatch in github action
I'll also add here an example that can be useful to understand how to use the repository_dispatch event to receive a callback from the other workflow to the first one:
workflow A
workflow B
Note that you will also need to use a PAT to trigger a workflow using a dispatch event.

Auto trigger gitlab cicd when code changes in github repo

I am using Github for code and using GitLab CiCd for pipeline, Manual trigger is working fine but I am trying to auto trigger the pipeline when the new Changes is pushes to the code. Please suggest ideas.
You could use a Gitlab CI action from a Github repository workflow with Github Actions.
Action example: Trigger Gitlab CI Job
Note: Others Github Actions interacting with Gitlab can be found on the marketplace
Github Action workflow example:
name: trigger gitlab job
on: [push]
jobs:
build:
name: Build
runs-on: ubuntu-latest
steps:
- name: trigger Job
uses: appleboy/gitlab-ci-action#master
with:
url: "http://example.com"
token: ${{ secrets.TOKEN }}
project_id: 100
Where the input variables are:
token - Required. A unique trigger token can be obtained when adding a new trigger.
project_id - Required. project id.
ref - Optional. Triggers can be used to force a pipeline rerun of a specific ref (branch or tag) with an API call. Default as master.

How to use snippets in Github action workflow file to avoid duplicates?

Problem: We use github actions workflow for CI and we have many github repositories. I need to be able change everything repeatable for every repository at once.
Is it possible to use in github action workflow yml file some snippet that located mb in different repository.
You can include other public and local actions in your workflow, which lets you reuse common steps. Using versioned actions with {owner}/{repo}#{ref}:
steps:
- uses: actions/setup-node#74bc508 # Reference a specific commit
- uses: actions/setup-node#v1 # Reference the major version of a release
- uses: actions/setup-node#v1.2 # Reference a minor version of a release
- uses: actions/setup-node#master # Reference a branch
..or local actions with ./path/to/dir:
jobs:
my_first_job:
steps:
- name: Check out repository
uses: actions/checkout#v2
- name: Use local my-action
uses: ./.github/actions/my-action
https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsuses
One way of doing this is having a central CICD / GitHub actions repository with shared workflows which are triggered on repository_dispatch events.
on:
repository_dispatch:
types:
- your_event
jobs:
job1:
name: Do something
runs-on: ubuntu-latest
env:
SOURCE_BRANCH: ${{ github.event.client_payload.source_branch }}
SOURCE_REPO: ${{ github.event.client_payload.source_repo }}
# do all your stuff
Then in each github repo you write a small workflow file which outlines the triggers for the local repo, pushing to master / opening a PR etc. That action simply dispatches a repository_dispatch event to your central CICD repo with the repo and branchname it came from.
name: Trigger external CICD
on:
push:
branches:
- master
jobs:
trigger_cicd:
name: Trigger external CICD
runs-on: ubuntu-latest
steps:
- name: Send repository_dispatch event
uses: peter-evans/repository-dispatch#v1
with:
token: ${{ secrets.CICD_GITHUB_TOKEN }}
repository: yourorg/centralcicdrepo
event-type: ${{ env.EVENT_TYPE }}
client-payload: '{"source_branch": "${{ github.ref }}", "source_repo": "${{ github.repository }}" }'
One gotcha is that you need an access token to talk between repos, in the above example it's added as a secret called CICD_GITHUB_TOKEN. The easiest is to just use your own account but this will label all your central CICD runs as 'triggered by you'. You can also create a bot account or you can have each developer add their access tokens as secrets then map the right author to the right access token.
There is currently (Feb. 3, 2021) no supported method for reusing workflows or snippets from a centralized repository. There are hacks, as Michael Parker has cleverly demonstrated, but these come with significant downsides (eg. observability, opacity, etc.).
I've written this blog post that describes the problem you have in more detail, along with an open-source solution.
––
Similar topics:
DRYing GH Actions workflows
External workflow configuration
Bringing this issue to GH's attention:
Raise this issue with GH
GH Roadmap item