Hack for LA's GitHub Actions
Is this guide outdated? Feel free to open a new issue so that a developer can work on updating it!
GitHub Actions (GHAs) are pieces of code that run once a trigger...triggers. These triggers can be nearly anything that can happen on GitHub, such as when a pull request is created, or a comment is made on an issue. Traditionally, GitHub Actions is used to perform unit tests whenever a pull request is created. The GHA would ensure that the new code does not break the website. However, with a bit of creativity, GitHub Actions can do so much more! This wiki outlines the way we organize our GitHub actions, provides a mini-guide to get started on your own and some tips if you ever need help.
GitHub Actions at HackForLA lives in two main directories, the .github/workflows directory and the github-actions directory. Much like how our project has a folder for overall pages, and a folder for pieces that we include into those layouts, the two github actions folder follow a frame-details relationship. That is, the .github/workflows directory frames the conditioned in which the action would activate and the github-actions directory details how those actions are performed.
This is a summary of our file structure. Please refer back to this often if you are ever confused!
├── .github
│ └── workflows
| ├── issue-trigger.yml
| ├── lint-scss.yml
| └── pull-request-trigger.yml
├── github-actions
│ ├── trigger-issue # Named after a trigger
| ├── job1 # Named after a job
| ├── *.js # Named after a step
| └── *.js # Named after another step
| └── job2
| ├── *.js
| └── *.js
| ├── trigger-pr
| ├── ...
| └── ...
| ├── trigger-schedule
| ├── ...
| └── ...
│ └── utils
| └── *.jsThe .github/workflows directory contains 3 overarching framing files: issue-trigger.yml, lint-scss.yml, and pull-request-trigger.yml. These files are named after their triggers. For example, in the below snippet, the GHA triggers on a pull request that is either opened, closed, or edited.
Note on the other files
The other files in that folder are GHAs that has not yet been incorporated into issue-trigger.yml, lint-scss.yml, or pull-request-trigger.yml. These files, depending on their triggering condition, should eventually be refactored into them (in fact, there are probably issues on them if you type in ['refactoring ghas'][#refactorgha] in the issue search bar.
pull-request-trigger.yml
name: Pull Request Trigger
on:
pull_request:
types: [opened, closed, edited]
branches:
- 'gh-pages'Further more, these triggers are further subdivided through if-else clauses into different jobs, or actions that are taken when the trigger condition is fulfilled. In the below snippet, there are two overarching jobs: Add-Issue-Labels-To-PR and Add-Reviewers-To-New-PR. These jobs only activate when a pull request is opened. Once activated, they perform a series of instructions, called steps (which is not written out here to conserve space).
These steps are usually written in ubuntu commandline code, which is a powerful language for file maintenance and manipulation (those familiar with commandline code will realize that GHAs are a lot like cron jobs).
pull-request-trigger.yml
jobs:
Add-Issue-Labels-To-PR:
runs-on: ubuntu-latest
# Only trigger when a new PR is created
if: ${{ github.event_name == 'pull-request' && github.event.action == 'opened'}}
steps:
- run: echo "Hello World! 🎉"
...
Add-Reviewers-To-New-PR:
runs-on: ubuntu-latest
# Only trigger when a new PR is created
if: ${{ github.event_name == 'pull-request' && github.event.action == 'opened'}}
steps:
- run: echo "Hello World! 🎉"
...To summarize, the thing to remember about these files are that they are named after triggers, and that each job uses if/else clauses to specify the specific trigger that causes the GHA to run.
For most developers, the ubuntu shell is either too arcane or too lacking to perform very tailored actions. Therefore, we often abstract away the ubuntu code by running an external JS file instead. This external file, and all files that support it, lives in the second GHA directory: the github-actions directory.
The github-actions directory houses all the JS files that are called or used by the .yml files in the .github/workflows. These files are usually called via two external modules called actions/checkout@v2 and actions/github-script@v4. Their functions will not be detailed here, as that can be found in their documentation. However, I will say that these two work in tandem to allow GHAs to call our JS files.
issue-trigger.yml
steps:
- uses: actions/checkout@v2
- name: Check Labels
uses: actions/github-script@v4
id: check-labels
with:
script: |
const script = require('./github-actions/trigger-issue/add-missing-labels-to-issues/check-labels.js')
const checkLabels = script({g: github, c: context})
return checkLabels
- name: Post Comment
uses: actions/github-script@v4
with:
script: |
const results = ${{ steps.check-labels.outputs.result }}
const script = require('./github-actions/trigger-issue/add-missing-labels-to-issues/post-labels-comment.js')
script({g: github, c:context}, results)
In the above sample, you will notice that the script is called by giving it a github and context object. These two objects are provided by the actions/github-script@v4 module, respectively serving as an entryway into the GitHub API and the data containing the context of the trigger.
Note how every step in the GHA has a name (above, the names are Check Labels and Post Comment). These names are there to broadly define the steps of that particular action.
Also, note the path of the called JS files, trigger-issue/add-missing-labels-to-issues/check-labels.js and trigger-issue/add-missing-labels-to-issues/check-labels.js. These paths follow the pattern of trigger/jobname/stepname.js. This organization allows us to very quickly locate the JS file that is associated with some action, and quickly surmise its purpose. This helps us edit the files quickly, since most GHAs involves very similar tasks, and so a very nested structure is needed to not confuse files such as add-update-label-weekly.js vs add-label-on-issue-creation.js.
Jumping into the github-actions directory, you will see four main directories: trigger-issue, trigger-pr, trigger-schedule, and utils. The first three are related to the aforementioned triggers, while utils contains code that can be reused by multiple JS files in the trigger-* directories.
Note
The other folders have not yet been incorporated into the trigger-issue, trigger-pr, and trigger-schedule directories. These files, depending on their triggering condition, should eventually be refactored into them (in fact, there are probably issues on them if you type in 'refactoring ghas' in the issue search bar.
To summarize, the important things to know about the github-actions directory is that they house the js and other files involving GHAs in a nested pattern, trigger/jobname/stepname.js, and that the js file is called by the yml files in the .github/workflows directory.
This mini-guide details a very hacky way for making GHAs. The reason why this is hacky is because it is a very specific way of making GHAs, but not the only way. This way often provides the quickest results by abstracting a lot of the arcane language and nuance, making it very friendly for web developers. In other words, this method uses a very specific boilerplate that simplifies GHAs. Note that this guide assumes you are familiar with the architecture outlines above, so I will not discuss about files and naming convention here.
Without further ado, let's begin.
To start, in the correct .yml file (remember, the .yml files are named based on triggers), paste the below snippet in the correct spot. Change the name of the job and the if/else clause as needed. Every GHA should only have one of this snippet.
jobs:
Add-Missing-Labels-To-Issues: # Replace this with the name of your job
runs-on: ubuntu-latest
if: ${{ github.event_name == 'issues' && github.event.action == 'opened'}} # Use as many && statements as needed to isolate your triggerClear version without comments
jobs:
Add-Missing-Labels-To-Issues:
runs-on: ubuntu-latest
if: ${{ github.event_name == 'issues' && github.event.action == 'opened'}}
After defining the job, below it, copy and paste the below step, and replace text as needed. Most GHAs should only need one or two of these, depending on how you want to subdivide the steps. As a rule of thumb, a step should do one overarching thing. A naive reader reading the file should be able to understand your GHA's function just by reading the steps.
steps:
- uses: actions/checkout@v2
- name: # Put the name of the step
uses: actions/github-script@v4
id: # Optional field, see docs for [actions/checkout@v2][#actionscheckout] for details
with:
script: |
const script = require('') // Put the relative path to the JS file, because the root is not what you think it is, trust
const checkLabels = script({g: github, c: context}) // Rename the const variable, but do NOT change anything else
return checkLabels // Optional return, see docs for [actions/checkout@v2][#actionscheckout] for details on how to use return statementsFor every step you have, create the correct directories (remember, the pattern is trigger/jobname/stepname.js) for where your js files should reside. For your js file, copy and paste the below boilerplate to get started.
// Import modules // Import whatever files or modules you need
// Global variables // Add whatever global variables you need
var github;
var context;
async function main({ g, c }) { // Add other variables as needed, but keep { g, c }
github = g; // DO NOT EDIT
context = c; // DO NOT EDIT
// TODO
// Write your code here.
}
module.exports = main // DO NOT EDITIn yml, much like with Python, spaces have meaning! If something does not work, it is often because your indentation was improper. The below snippet is from GHA's documentation. Examine it carefully, and make sure that your GHAs follow the same indentation levels.
name: GitHub Actions Demo # GHA name
on: [push] # Trigger
jobs:
Explore-GitHub-Actions: # Job name
runs-on: ubuntu-latest
steps:
- run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event." # Steps
- run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!"
- run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}."
- name: Check out repository code
uses: actions/checkout@v2 # Module
- run: echo "💡 The ${{ github.repository }} repository has been cloned to the runner."
- run: echo "🖥️ The workflow is now ready to test your code on the runner."
- name: List files in the repository
run: |
ls ${{ github.workspace }} # multi-line ubuntu code
echo "🍏 This job's status is ${{ job.status }}."Before writing any GHAs, make sure you skim through these references to make sure you understand the ins and outs of GHAs.
Quickstart for GitHub Actions
Learn GitHub Actions
Learn GitHub Actions/Events that trigger workflows
Learn GitHub Actions/Expressions
REST API/Reference
octokit/rest.js
actions/checkout
actions/github-script
Security guides
Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests
Keeping your GitHub Actions and workflows secure Part 2: Untrusted input
Keeping your GitHub Actions and workflows secure Part 3: How to trust your building blocks
steps:
- uses: actions/checkout@v2
- name:
uses: actions/github-script@v4
id:
with:
script: |
const script = require('') <-- relative path only!!!Testing GHAs on GitHub itself is a very slow process since you need to upload it to GitHub and trigger it yourself by making a pull request or issue or something else on your own repository. The better thing to do would be to break your code into small functions and test the code by feeding it dummy data.
Also, if you must run it on GitHub to test, use the workflow_dispatch trigger. If a certain context is needed, such as a PR number, you can always use dummy data again.