How Do You Set Up GitHub Actions for CI/CD in Your Repository?

How Do You Set Up GitHub Actions for CI/CD in Your Repository?

To set up GitHub Actions, create a YAML workflow file inside the .github/workflows/ directory of your repository. That file defines when the pipeline runs (on push, pull request, or a cron schedule), which operating system to use, and the sequence of steps — install dependencies, run tests, build artifacts, or deploy. GitHub detects the file automatically and starts executing your CI/CD pipeline on the next matching event.

GitHub Actions is GitHub's built-in CI/CD service. It lets you build, test, and deploy code without installing or managing a separate tool. Workflows run on GitHub-hosted virtual machines, and the Actions Marketplace provides thousands of reusable actions so you rarely need to write everything from scratch.

What Is a GitHub Actions Workflow?

A workflow is an automated process defined in a YAML file. Workflows are triggered by events — pushes, pull requests, tag creation, manual dispatch, or cron schedules. When an event fires, GitHub runs the workflow on a hosted virtual machine.

Every workflow contains one or more jobs, and every job contains a list of steps. Each step is either a shell command (run) or a reference to a reusable action (uses). Jobs within the same workflow run in parallel by default, but you can configure dependencies between them.

Key concepts:

  • Event: What triggers the workflow (push, pull_request, schedule, workflow_dispatch)
  • Job: A group of steps that execute on the same runner
  • Step: A single command or action
  • Action: A reusable unit of code from the Marketplace or your own repository
  • Runner: The virtual machine that executes the job

If you need to run a workflow on a schedule, the schedule event accepts standard cron syntax. For example, cron: '0 6 * * 1' runs every Monday at 6 AM UTC.

How Do You Create a GitHub Actions Workflow File?

Create a .yml or .yaml file inside .github/workflows/ at the root of your repository. Here is a complete example that runs a Laravel test suite on every push and pull request to the master branch:

File path: .github/workflows/laravel.yml

name: Laravel

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  laravel-tests:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Copy .env
      run: php -r "file_exists('.env') || copy('.env.example', '.env');"
    - name: Install Dependencies
      run: composer install -q --no-ansi --no-interaction --no-scripts --no-progress --prefer-dist
    - name: Generate key
      run: php artisan key:generate
    - name: Directory Permissions
      run: chmod -R 777 storage bootstrap/cache
    - name: Create Database
      run: |
        mkdir -p database
        touch database/database.sqlite
    - name: Execute tests (Unit and Feature tests) via PHPUnit
      env:
        DB_CONNECTION: sqlite
        DB_DATABASE: database/database.sqlite
      run: vendor/bin/phpunit

Once pushed, open the Actions tab in your GitHub repository to see the workflow running.

GitHub Actions running Laravel tests — workflow output showing a successful build

Click the triangle icon on any step to expand its output and inspect the result.

Expanded PHPUnit test step output in GitHub Actions showing passing tests

What does each part of the workflow file do?

SectionPurpose
nameDisplay name shown in the Actions tab
onEvents that trigger the workflow (push, pull_request, schedule)
jobsOne or more jobs to run. Each job gets its own runner
runs-onThe virtual environment for the job (e.g., ubuntu-latest)
stepsOrdered list of commands and actions to execute
usesReferences a reusable action (e.g., actions/checkout@v2)
runExecutes a shell command
envSets environment variables for a step

What Reusable Actions Are Available in the Marketplace?

The GitHub Actions Marketplace contains thousands of community and vendor-maintained actions. Adding one to your workflow takes a single uses line.

Commonly used actions include:

If no existing action fits your needs, you can create your own action and publish it to the Marketplace.

What Virtual Environments Can GitHub Actions Run On?

GitHub Actions supports Linux, macOS, and Windows as runner environments. Each runner provides the following resources:

  • 2-core CPU
  • 7 GB of RAM
  • 14 GB of SSD disk space

Set the runner with the runs-on key in your job definition. Available environments:

LabelOperating System
ubuntu-latestUbuntu (latest LTS)
ubuntu-24.04Ubuntu 24.04
ubuntu-22.04Ubuntu 22.04
windows-latestWindows Server (latest)
windows-2022Windows Server 2022
macos-latestmacOS (latest)
macos-14macOS 14 (Sonoma, Apple Silicon)
macos-13macOS 13 (Ventura, Intel)

Because the runner is a full virtual machine, you can install system packages with apt-get, run Docker containers, build and push images, or execute any command you would run locally.

How Much Do GitHub Actions Cost?

GitHub Actions is free for public repositories with unlimited minutes. For private repositories, every plan includes free minutes each month:

PlanFree Minutes/MonthFree Storage
Free2,000500 MB
Pro3,0001 GB
Team3,0002 GB
Enterprise50,00050 GB

If you exceed the free minutes, additional usage is billed per minute based on the runner OS:

Runner OSCost per Minute
Linux (2-core)$0.008
Windows$0.016
macOS$0.08

For most small teams and side projects, the free tier is more than enough. The 2,000 free minutes on the Free plan translate to roughly 33 hours of Linux build time per month.

Which CI/CD Tool Should You Choose?

GitHub Actions is the best starting point for most developers. It requires zero setup beyond a YAML file, integrates directly with your GitHub repository, has the largest ecosystem of reusable actions, and offers the most generous free tier of any major CI/CD service. If your code is already on GitHub, there is no reason to use a separate CI/CD tool.

For a detailed comparison with Bitbucket Pipelines and GitLab CI/CD — including syntax differences, OS support, and pricing breakdowns — see the full CI/CD tool comparison.

Once your CI/CD pipeline builds and tests your code, you still need somewhere to deploy it. Deckrun handles the deployment side — ship to managed cloud infrastructure with a single deck deploy command, no Kubernetes expertise required. Your GitHub Actions workflow builds and tests; Deckrun deploys.

Frequently Asked Questions

Is GitHub Actions free?

Yes, for public repositories GitHub Actions is completely free with unlimited minutes. Private repositories on the Free plan get 2,000 minutes per month at no cost. Paid plans increase the free allowance up to 50,000 minutes per month on Enterprise.

What languages and frameworks does GitHub Actions support?

GitHub Actions supports any language or framework that can run on Linux, macOS, or Windows. There are official setup actions for Node.js, Python, Java, .NET, Go, Ruby, and more. If your language is not covered by an existing action, you can install it manually in a run step.

Can GitHub Actions deploy to production?

Yes. GitHub Actions can deploy to any target — cloud providers (AWS, GCP, Azure, DigitalOcean), container registries, Kubernetes clusters, FTP servers, or platforms like Deckrun. The Marketplace has deployment actions for most providers. You can also use SSH or CLI-based deployments in a run step.

How do I debug a failing GitHub Actions workflow?

Enable debug logging by setting the repository secret ACTIONS_STEP_DEBUG to true. This adds verbose output to every step. You can also add run: env steps to print environment variables, use the actions/upload-artifact action to save log files, or run workflows locally with tools like act.

What is the difference between GitHub Actions and GitHub Apps?

GitHub Actions is a CI/CD service that runs workflows in response to repository events. GitHub Apps are integrations that extend GitHub's functionality through the API (bots, code review tools, project management). They serve different purposes — Actions automates builds and deployments, while Apps add features to the GitHub UI and API.

$ subscribe --newsletter

Improve how you build, deploy, and scale.

Get cloud development tips that make life easier, right in your inbox