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.
Click the triangle icon on any step to expand its output and inspect the result.
What does each part of the workflow file do?
| Section | Purpose |
|---|---|
name | Display name shown in the Actions tab |
on | Events that trigger the workflow (push, pull_request, schedule) |
jobs | One or more jobs to run. Each job gets its own runner |
runs-on | The virtual environment for the job (e.g., ubuntu-latest) |
steps | Ordered list of commands and actions to execute |
uses | References a reusable action (e.g., actions/checkout@v2) |
run | Executes a shell command |
env | Sets 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:
- actions/checkout — checks out your repository (required in almost every workflow)
- actions/setup-node — installs a specific Node.js version
- actions/cache — caches dependencies to speed up builds
- configure-aws-credentials — authenticates with AWS for deployments
- docker/build-push-action — builds and pushes Docker images
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:
| Label | Operating System |
|---|---|
ubuntu-latest | Ubuntu (latest LTS) |
ubuntu-24.04 | Ubuntu 24.04 |
ubuntu-22.04 | Ubuntu 22.04 |
windows-latest | Windows Server (latest) |
windows-2022 | Windows Server 2022 |
macos-latest | macOS (latest) |
macos-14 | macOS 14 (Sonoma, Apple Silicon) |
macos-13 | macOS 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:
| Plan | Free Minutes/Month | Free Storage |
|---|---|---|
| Free | 2,000 | 500 MB |
| Pro | 3,000 | 1 GB |
| Team | 3,000 | 2 GB |
| Enterprise | 50,000 | 50 GB |
If you exceed the free minutes, additional usage is billed per minute based on the runner OS:
| Runner OS | Cost 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.