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