Automate Your Workflows with GitHub Actions and GitHub Packages

🔖 The following instructions will take on the assumption that you will be completing the steps on the GitHub UI. Feel free to use the terminal or any other GUIs you are comfortable with.

Workflow 1: Steps to set up CI workflow

This repository comes with npm project files, namely package.json (contains your node project meta data) and index.js (your source code).
Fork this repository and edit the package.json file by replacing the placeholders OWNER with your GitHub handle or organization name (if you created the repository in an organization), and REPOSITORY_NAME.
Create the following file to the default branch:
- .github/workflows/ci.yml
  - This will be the workflow file taking care of building and testing your source code
  - The file content will be empty for now
After the above steps are finished, you should have the following files in your repository;
- package.json
- index.js
- .github/workflows/ci.yml
🎉 If everything looks fine so far, it's time to start creating our CI workflow!

Go to .github/workflows/ci.yml and enter edit mode by clicking the pencil 📝 icon

Click here to view file contents to copy:

#####################################
#      Automate your workflow       #
#####################################

# This workflow will run CI on your codebase, label your PR, and comment on the result

name: MYWORKFLOW

on:
  pull_request: # the workflow will trigger on every pull request event

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [12.x, 14.x] # matrix for building and testing your code across multiple node versions

    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Build node version ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
            node-version: ${{ matrix.node-version }}
      - run: npm install
      - run: npm run build --if-present
      - run: npm test

  label:
    runs-on: ubuntu-latest

    needs: build #this ensures that we only trigger the label job if ci is successful

    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - uses: actions/github-script@v3
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            github.issues.addLabels({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              labels: ['release']
            })

  comment:
    runs-on: ubuntu-latest

    needs: [build, label]

    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Comment on the result
        uses: actions/github-script@v3
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            github.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `
              Great job **@${context.payload.sender.login}**! Your CI passed, and the PR has been automatically labelled.

              Once ready, we will merge this PR to trigger the next part of the automation :rocket:
              `
            })

Update the name of your workflow
Within the comment job, you can edit the body of the comment as you see fit
Commit the changes to your default branch
Knowledge Check
- How many jobs are there in the workflow?
  Answer
  The workflow contains three jobs:
  - a build-job,
  - a label-job,
  - a comment-job
- What is the event that will trigger this workflow?
  
  Answer
  The workflow is triggered by any pull request events.
- Does this workflow use a build matrix?
  
  Answer
  Yes, this workflow will build and test across multiple node versions.

🎉 Awesome, now our CI workflow should be complete!

Test the CI Workflow

To test our CI workflow, we need to trigger it. And the event that triggers it is pull_request. So let's create a pull request to get this workflow running
Go to index.js file and enter edit mode.
Make some changes/add some text.
Commit your changes to a new branch e.g. add-ci-workflow and click Commit changes
In the pull request, leave the title and the body to default and click Create pull request
In your PR, click on the Checks tab
- You should now see your workflow kicking off, and executing all the steps defined in .github/workflows/ci.yml
After the workflow has completed, check that the following is true in your PR;
- A label release has been added
- A comment is added to the PR with the text corresponding to what you defined in the comment job inside .github/workflows/ci.yml
If your workflow fails, inspect the log output:
- Which job failed?
- Did you update your package.json file correctly?
- Does the log indicate any syntax errors with your CI workflow file?

⚠️ Do not merge your pull request just yet! There's more to do.

Workflow 2: Steps to set up release and publish package workflow

Add a workflow that publishes an NPM package and creates a draft release

We are going to be using the release-drafter Action.

Add a workflow file at this directory .github/workflows/release.yml:

Click here to view file contents to copy:

#####################################
#      Automate your workflow       #
#####################################

# This workflow will create a NPM package and a new release

name: Publish and release

on:
  push:
    # branches to consider in the event; optional, defaults to all
    branches:
      - main

jobs:

  update_release_draft:
    runs-on: ubuntu-latest

    steps:
      # Drafts your next Release notes as Pull Requests are merged into "master"
      - uses: release-drafter/release-drafter@v5
        with:
          config-name: release-drafter-config.yml
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  publish-gpr:
    runs-on: ubuntu-latest

    needs: update_release_draft

    steps:
      - uses: actions/checkout@v2

      - uses: actions/setup-node@v1
        with:
          node-version: 12
          registry-url: https://npm.pkg.github.com/

      - run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Notice how this workflow calls for a special config file called release-drafter-config.yml. This is a config file that allows you to add more customization. So let's go ahead and add a config file for this action at github/release-drafter-config.yml:

Click here to view file contents to copy:

name-template: 'v$RESOLVED_VERSION 🌈'
tag-template: 'v$RESOLVED_VERSION'
categories:
  - title: '🚀 You did it!'
    labels:
      - 'release'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
change-title-escapes: '\<*_&' # You can add # and @ to disable mentions, and add ` to disable code blocks.
version-resolver:
  major:
    labels:
      - 'major'
  minor:
    labels:
      - 'minor'
  patch:
    labels:
      - 'patch'
  default: patch
template: |
  ## Changes

  $CHANGES

You can read more about the configuration options for this Action here.
This action will create a release with release notes when the pull request is merged into the main branch.

Watch your actions come to life!

Merge the pull request
Click on the Code tab and click on Packages on the right sidebar to find your package
Click on Releases on the right sidebar to find your new draft Release

Additional Exercise

Customize your release-drafter Action such that it is able to categorize release notes based on labels that were added to pull requests. For example, if the label bugfix is added to a pull request, then when the pull request is merged, the Action would add the pull request to the release notes and show it as a Bugfix. Here's an example:

You can find out how to add more customizations from the configuration options for this Action here.

Click here to see the example

name-template: 'v$RESOLVED_VERSION 🌈'
tag-template: 'v$RESOLVED_VERSION'
categories:
  - title: '🚢 Features'
    labels:
      - 'feature'
      - 'enhancement'
  - title: '🐛 Bug Fixes'
    labels:
      - 'fix'
      - 'bugfix'
      - 'bug'
  - title: '🧰 Maintenance'
    label: 'chore'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
change-title-escapes: '\<*_&' # You can add # and @ to disable mentions, and add ` to disable code blocks.
version-resolver:
  major:
    labels:
      - 'major'
  minor:
    labels:
      - 'minor'
  patch:
    labels:
      - 'patch'
  default: patch
template: |
  ## Changes

  $CHANGES

The config file above allows you to add more labels like 'feature' and 'bug'.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

README.md

README.md

Automate Your Workflows with GitHub Actions and GitHub Packages

Workflow 1: Steps to set up CI workflow

Test the CI Workflow

Workflow 2: Steps to set up release and publish package workflow

Add a workflow that publishes an NPM package and creates a draft release

Watch your actions come to life!

Additional Exercise

Files

README.md

Latest commit

History

README.md

File metadata and controls

Automate Your Workflows with GitHub Actions and GitHub Packages

Workflow 1: Steps to set up CI workflow

Test the CI Workflow

Workflow 2: Steps to set up release and publish package workflow

Add a workflow that publishes an NPM package and creates a draft release

Watch your actions come to life!

Additional Exercise