Closed github-learning-lab[bot] closed 2 years ago
Great job creating a new workflow!
As we briefly discussed earlier, workflows can be configured to run:
Full details are available in Events that trigger workflows on GitHub Help. So far, we've used the push
event for our Node.js workflow. That makes sense when we want to take action on code changes to our repository.
For a review workflow, we want to engage with human reviews, instead. For example, we'll use the Label approved pull requests action so that we can easily see when we've gotten enough reviews to merge a pull request.
Let's prep our review workflow by triggering it with a pull_request_review
event.
Great work! Let's get some more practice with jobs. Apply the suggested change below or follow the instructions.
In a later step, we'll use an action that adds a label to any pull requests after a preset number of approvals. These labels could be used as a visual indicator to your team that something is ready to merge, or even as a way to use other actions or tools to automatically merge pull requests when they receive the required number of approvals.
We've now got a job with the labelWhenApproved
identifier. We're off to a great start!
It's now time to use a community-created action. The action we'll use is pullreminders/label-when-approved-action.
Let's see if you can use this action on your own.
If you'd like a hint, submit a comment on this pull request with the word "hint".
steps:
blockuses:
keywordlabel-when-approved-action
requires a block called env:
with the following environment variables:
APPROVALS
is the number of required approvals that are required for a label to be applied, please set this to "1"
GITHUB_TOKEN
is necessary so the action can create and apply labels to this repository. See the action's documentation for how to use itADD_LABEL
is the name of the label which should be added when the number of approvals have been met, choose any label name you wishI'll respond when you push a new commit to this branch.
Awesome! We can now check an additional requirement off our list!
main
branch can't be deleted or inadvertently brokenWe'll now use branch protections in combination with this change so that everything goes smoothly. Up until now, I've handled branch protections for you, but I've removed them so that you can learn how to set them.
Take a look at the merge box, you'll notice you can merge this even though the review process hasn't been met. Still see the protection? Refresh this page.
Protected branches ensure that collaborators on your repository cannot make irrevocable changes to branches. Enabling protected branches also allows you to enable other optional checks and requirements, like required status checks and required reviews.
Next, add branch protections and continue with the course.
main
in Branch name pattern.I'll respond when I receive an approval from your pull request review.
Awesome work! Our workflows are now complete.
GitHub Actions will apply a label to this pull request because you've approved it. This may take a few moments to run, you can follow along in the Actions tab.
Labeling the pull request allows us to automate the merging of pull requests. I'll act as the :robot: automation in this example and merge the pull request for you.
Let's go to the next step.
Partial workflow
Remember the custom workflow we are attempting to create for the team? Here's our status on the list of requirements we defined:
main
branch can't be deleted or inadvertently brokenThe last three remaining items don't really belong in a
code, build, and test
pipeline because they have to do with processes that involve humans.Step 14: Automate the review process
GitHub Actions can run multiple workflows for different event triggers. Let's create a new approval workflow that'll work together with our Node.js workflow.
:keyboard: Activity: Add a new workflow file to automate the team's review process
.github/workflows/approval-workflow.yml
, on this branchI'll respond when you commit to this branch.