A custom workflow

[github-learning-lab]

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:

• ✅ test against multiple targets so that we know if our supported operating systems and Node.js versions are working
• ✅ dedicated test job so that we can separate out build from test details
• ✅ access to build artifacts so that we can deploy them to a target environment
• branch protections so that the main branch can't be deleted or inadvertently broken
• required reviews so that any pull requests are double checked by teammates
• obvious approvals so we can merge quickly and potentially automate merges and deployments

The 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.

⌨️ Activity: Add a new workflow file to automate the team's review process

1. Create a new file, .github/workflows/approval-workflow.yml, on this branch
2. Enter a name for your workflow in the new file, something like:

   name: Team awesome's approval workflow

I'll respond when you commit to this branch.

[github-learning-lab]

Choose the event

Great job creating a new workflow!

As we briefly discussed earlier, workflows can be configured to run:

• Using events from GitHub
• At a scheduled time
• When an event outside of GitHub occurs

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.

[github-learning-lab]

Add a job

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.

[github-learning-lab]

Add a step

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.

Step 17: Automate approvals

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".

Here's some tips to get you going:

• the workflow file needs a steps: block
• give your new step any name you wish
• to use a community action, use the uses: keyword
• label-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 it
  • ADD_LABEL is the name of the label which should be added when the number of approvals have been met, choose any label name you wish

⌨️ Activity: Use the community action to automate part of the review approval process

1. Using your prior knowledge, configure the pullreminders/label-when-approved-action action in this workflow

I'll respond when you push a new commit to this branch.

[github-learning-lab]

Our workflow

Awesome! We can now check an additional requirement off our list!

• ✅ test against multiple targets so that we know if our supported operating systems and Node.js versions are working
• ✅ dedicated test job so that we can separate out build from test details
• ✅ access to build artifacts so that we can deploy them to a target environment
• ✅ obvious approvals so we can merge quickly and potentially automate merges and deployments
• branch protections so that the main branch can't be deleted or inadvertently broken
• required reviews so that any pull requests are double checked by teammates

We'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.

Step 18: Use branch protections

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.

⌨️ Activity: Complete the automated review process by protecting the main branch

1. Go to Branches settings. You can navigate to that page manually by clicking on the right-most tab in the top of the repository called Settings and then clicking on Branches.
2. Click on Add rule under "Branch protection rules".
3. Type main in Branch name pattern.
4. Check Require pull request reviews before merging.
5. Check Require status checks to pass before merging.
6. Check all build and test jobs that you'd like to see in the newly visible gray box.
7. Click Create.
8. Return to this pull request, and approve the requested review.

I'll respond when I receive an approval from your pull request review.