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
Using `workflow_run` in pull requests from non-default branches or forks
Git newbie: What is a good workflow for a solo/small team on a WIP project (many and fast releases)?
Git is a very powerful tool. If you use its full power, you can benefit a lot from it.
I am assuming that you're using GitHub to host your code. My suggestion for a good workflow would be: (assuming you already have setup your repo on GitHub and your code is on the master branch)
-
Pull in the code onto your machine by using the command
git pull origin master. -
Create a new branch for changes you want to make using
git checkout -b new_branch_name -
Make changes or add new code.
-
git diffyour code and verify that the changes you have are the desired ones. -
git add .(Although many developers prefer not adding all the files directly). If you want to be extra careful while staging your files, usegit add -i. This will start an interactive session. -
git commit -m "Good, sensible, imperative commit message". -
git push origin new_branch_name -
From your
new_branch_namebranch on GitHub, send a pull request to merge onto yourmasterbranch. Your pull request will act as a place to review your code. Your team-mates can review your code and suggest necessary changes. -
If everything is fine, switch to
masterbranch locally and pull in the latest changes using the following commands:git checkout master-->git pull origin master-->git merge new_branch_name. One thing that needs to be taken care of here would be that it is always a better practice to mergemasterbranch onto yournew_branch_nameand resolve conflicts and then merge this code back ontomasterafter testing thenew_branch_namebranch and making sure all your tests pass. -
Once the merged, conflict resolved, test passing code is on
master, push the changes tomasterbranch by using the commandgit push origin master.
BONUS: If you have a git based deployment system, create a branch called production and merge your changes from master onto production by git checkout -b production && git merge master && git push origin production. Now this will be the only code you'll use to pull on your production setup.
The thing about this sort of workflow is that it will scale. When your team grows, you can still follow the same workflow. This is more or less how a basic Git workflow would be like. Hope that was what you were looking for.
EDIT: Thanks to "tchebb", I've updated the 6th point. When manually staging (git add .) all the files, you can commit the changes using only the -m flag.