Read Anthropic’s case study about Graphite Reviewer

GitHub actions beginner guide

Greg Foster
Greg Foster
Graphite software engineer


Note

This guide explains this concept in vanilla Git. For Graphite documentation, see our CLI docs.


This guide provides an overview of GitHub Actions, covering its common use cases, and offers a basic tutorial on how to get started.

GitHub Actions allows you to automate, customize, and execute your software development workflows right within your GitHub repository. You can write individual tasks, known as actions, and combine them to create a custom workflow. Workflows are defined in YAML syntax and can be triggered by various GitHub events, such as pushing to a branch or tagging a release. GitHub Actions is mainly used to trigger custom workflows in response to GitHub events.

By creating custom workflows, developers can automate tasks such as CI/CD (Continuous Integration/Continuous Deployment), code linting, and testing every time they push code or make a pull request.

  • CI/CD pipelines: Automate the build, test, and deployment phases of your application whenever there is a push or pull request.

  • Automating scripts: Run scripts for linting, formatting, or any custom scripts based on specific triggers.

  • Project management: Automatically add labels to issues, assign reviewers to pull requests, or manage project boards.

  1. Explore the GitHub Actions documentation: Start with the GitHub Actions documentation to understand the basics, including the GitHub Actions syntax, workflow, and available actions in the GitHub Actions library.

  2. Understand the GitHub actions syntax and workflow: GitHub Actions are defined in YAML files within the .github/workflows directory of your repository. The basic syntax includes on, which defines the trigger for the workflow, and jobs, which specify the set of actions that will be executed.

  3. Create Your first workflow:

    • Navigate to your GitHub repository.

    • Click on the "Actions" tab, then click "New workflow".

    • You can start with a template or create a custom workflow by clicking "set up a workflow yourself".

Terminal
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Run a one-line script
run: echo Hello, world!
- name: Run a multi-line script
run: |
echo "Add other commands here"
echo "This is a multi-line script"

This example defines a workflow named "CI" that triggers on every push event. It consists of a single job named build, which checks out the code and runs a couple of scripts on an Ubuntu runner.

  • name: This field is for the name of the workflow. In this example, it's named "CI". The name is displayed on the GitHub Actions page of your repository whenever the workflow is triggered. This helps you and others identify the workflow purpose at a glance.

  • on: This key determines the event that triggers the workflow. In this case, [push] means that the workflow runs every time someone pushes code to any branch in the repository. You can specify multiple events and even configure event specifics, such as branches or paths that trigger the workflow.

  • jobs: Workflows are made up of one or more jobs. Jobs are a set of steps that execute on the same runner. By default, jobs run in parallel, but you can configure them to run sequentially if needed.

    • build: This is the identifier for the job. You can name it anything, but it's best to choose a name that reflects the job's purpose. In this example, it's called "build", implying that this job might include steps to compile or build your code.

      • runs-on: Specifies the type of machine to run the job on. GitHub Actions provides various runners (virtual environments) like Windows, macOS, and different versions of Linux. ubuntu-latest refers to the latest Ubuntu Linux runner provided by GitHub Actions.

      • steps: Jobs are composed of steps. Each step can either run a script or an action, and they execute in sequence. If a step fails, the job stops, and, consequently, the workflow might fail as well.

        • uses: This specifies an action to use as part of a step. Actions are reusable pieces of code that perform a specific task. In this example, actions/checkout@v2 is a commonly used action that checks out your repository under $GITHUB_WORKSPACE, so your workflow can access it.

        • name: This provides a name for the step. Giving each step a descriptive name is helpful for understanding what each part of your workflow does, especially when you're debugging.

        • run: This key is used to execute command-line programs and scripts. In the example, the run field is used twice to execute simple shell commands. The first run command executes a simple echo statement, while the second executes a multi-line script. You can use this to run build scripts, test suites, and any other commands available in the runner environment.

  • Leverage marketplace actions: Browse the GitHub Marketplace for actions that can automate your workflows. This can range from deploying to cloud providers to sending notifications.

  • GitHub actions for CI/CD: Integrate actions that build, test, and deploy your code to streamline your development process.

  • Utilize the GitHub actions UI: The GitHub Actions UI helps you visualize workflows, monitor progress, and debug issues.

GitHub Actions is a tool that can automate many aspects of your software development process. By understanding the basics of GitHub Actions syntax and exploring common use cases, you can start creating custom workflows to build, test, and deploy your projects efficiently. The key is to experiment with different actions and workflow configurations to find what best fits your development workflow.

For further reading on GitHub Actions see the official GitHub documentation.

Graphite
Git stacked on GitHub

Stacked pull requests are easier to read, easier to write, and easier to manage.
Teams that stack ship better software, faster.

Or install our CLI.
Product Screenshot 1
Product Screenshot 2