Closed github-learning-lab[bot] closed 4 years ago
GitHub Actions features powerful controls for when to execute jobs and the steps within them. One of these controls is if
, which allows you run a job only when a specific condition is met. See jobs.<job_id>.if
in Workflow syntax for GitHub Actions for more information.
Workflows are part of the GitHub ecosystem, so each workflow run gives you access to a rich set of data that you can use to take fine-grained control.
We'd like to run our workflow on a specific label called stage, so we'll achieve this in a single line that packs a punch. We'll use:
if:
is the conditional that will decide if the job will runcontains()
is a function that allows us to determine if a value like say, a label named "stage"
, is contained within a set of values like say, a label array ["bug", "stage", "feature request"]
github.event.pull_request.labels
is specifically accessing the set of labels that triggered the workflow to run. It does this by accessing the github
object, and the pull_request
event that triggered the workflow.github.event.pull_request.labels.*.name
uses object filters to filter out all information about the labels, like their color or description, and lets us focus on just the label names. Let's put all this together to run our job only when a labeled named "stage" is applied to the pull request.
deploy-staging.yml
file on this branch, or use this quick link (We recommend opening the quick link in another tab)Your results should look like this:
name: Staging deployment
on:
pull_request:
types: [labeled]
jobs:
build:
runs-on: ubuntu-latest
if: contains(github.event.pull_request.labels.*.name, 'stage')
So far, the workflow knows what the trigger is and what environment to run in. But, what exactly is supposed to run? The "steps" section of this workflow specifies actions and scripts to be run in the Ubuntu environment when new labels are added.
We won't be going into detail on the steps of this workflow, but it would be a good idea to become familiar with the actions we're using. They are:
The course Using GitHub Actions for CI also teaches how to use most of these actions in details.
Note: You may need a credit card to create an AWS account. If you're a student, you may also be able to take advantage of the Student Developer Pack for access to AWS. If you'd like to continue with the course without an AWS account, Learning Lab will still respond, but none of the deployments will work.
AWS_ACCESS_KEY
AWS_SECRET_KEY
.github/workflows/deploy-staging.yml
file to use a new action, or use this quick link (We recommend opening the quick link in another tab)
- name: Deploy to AWS
uses: github/deploy-nodejs@master
env:
AWS_ACCESS_KEY: ${{ secrets.AWS_ACCESS_KEY }}
AWS_SECRET_KEY: ${{ secrets.AWS_SECRET_KEY }}
If you'd like to copy the full workflow file, it should look like this:
name: Staging deployment
on:
pull_request:
types: [labeled]
jobs:
build:
if: contains(github.event.pull_request.labels.*.name, 'stage')
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: npm install and build webpack
run: |
npm install
npm run build
- uses: actions/upload-artifact@master
with:
name: webpack artifacts
path: public/
deploy:
name: Deploy Node.js app to AWS
needs: build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Download built artifact
uses: actions/download-artifact@master
with:
name: webpack artifacts
path: public
- name: Deploy to AWS
uses: github/deploy-nodejs@master
env:
AWS_ACCESS_KEY: ${{ secrets.AWS_ACCESS_KEY }}
AWS_SECRET_KEY: ${{ secrets.AWS_SECRET_KEY }}
Welcome to the course!
We'll learn how to create a workflow that enables Continuous Delivery. You'll:
Before you start, you should be familiar with GitHub and Continuous Integration. If you aren't sure where to start, you may want to check out these two Learning Lab courses:
What is Continuous Delivery?
Martin Fowler defined Continuous Delivery very simply in a 2013 post as follows:
A lot of things go into delivering "continuously". These things can range from culture and behavior to specific automation. In this course, we're going to focus on deployment automation.
Kicking off deployments
Every deployment is kicked off by some trigger. Engineers at many companies, like at GitHub, typically use a ChatOps command as a trigger. The trigger itself isn't incredibly important. In our use case, we'll use labels. When someone applies a "stage" label to a pull request, that'll be our indicator that we'd like to deploy our application to a staging environment.
Step 1: Configure a trigger based on labels
In a GitHub Actions workflow, the
on
step defines what causes the workflow to run. In this case, we want the workflow to run whenever a label is applied to the pull request.:keyboard: Activity: Configure the workflow trigger based on an a label being added
deploy-staging.yml
file on this branch, or use this quick link (We recommend opening the quick link in another tab)CHANGETHIS
toworkflows
, so the title of this file with the path is.github/workflows/deploy-staging.yml
Your result should look like this: