GitHub Actions
Native CI/CD built into GitHub. Automate tests, builds, and deployments with YAML workflows and a massive marketplace of actions.
Overview
GitHub Actions, launched in 2018, is GitHub's native continuous integration and continuous deployment (CI/CD) platform. It allows developers to automate software workflows directly from their GitHub repositories using YAML configuration files. With a marketplace of over 20,000 reusable actions, GitHub Actions can run tests, build containers, deploy to cloud providers, and integrate with virtually any tool.
In 2026, GitHub Actions is the most popular CI/CD platform for open-source projects and a leading choice for commercial teams. Its tight integration with GitHub repositories, pull requests, and issues makes it the natural choice for teams already using GitHub.
What it's used for
GitHub Actions is essential for:
- Automated testing: Run unit, integration, and E2E tests on every pull request.
- Multi-platform builds: Test on Ubuntu, Windows, and macOS runners simultaneously.
- Deployment automation: Deploy to AWS, Azure, GCP, Vercel, Netlify, and more.
- Security scanning: Integrate Snyk, SonarQube, and CodeQL into the pipeline.
- Release management: Automate versioning, changelogs, and artifact publishing.
Pros & Cons
Pros
- Native GitHub integration — no separate CI server needed
- Massive marketplace of reusable actions
- Free tier for public repos and generous free minutes for private repos
- Matrix builds for testing across OS and language versions
- Excellent documentation and community resources
Cons
- Vendor lock-in to GitHub ecosystem
- Debugging failing workflows can be frustrating
- Limited self-hosted runner management compared to Jenkins
- Pricing for large teams can escalate
- Some advanced CI features (caching, artifacts) have limitations
Platforms & Integrations
GitHub Actions runs on GitHub-hosted runners (Ubuntu, Windows, macOS) or self-hosted runners on any platform. It supports all major programming languages and frameworks.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Free | Free | 2,000 minutes/mo for private repos, unlimited for public repos |
| Team | $4/user/mo | 3,000 minutes/mo, advanced features, 2 GB storage |
| Enterprise | $21/user/mo | 50,000 minutes/mo, SAML SSO, audit logs, dedicated support |
NZ Context
GitHub Actions is the default CI/CD choice for NZ startups and open-source projects. GitHub is widely used in NZ, and Actions' tight integration makes it the path of least resistance. NZ government agencies using GitHub also adopt Actions for automated testing. For NZ developers, GitHub Actions YAML is becoming as fundamental as Git commands.
Alternatives
- GitLab CI — Built into GitLab with better self-hosted options.
- Azure DevOps — Microsoft's integrated CI/CD with strong enterprise features.
- Jenkins — Self-hosted, highly customisable, but requires more maintenance.
When to choose GitHub Actions
A quick decision guide for NZ teams evaluating CI/CD options.
| Choose GitHub Actions when… | Choose something else when… | Combine with… |
|---|---|---|
| Your source code already lives in GitHub and the team uses pull requests for all changes | Your org hosts code on Azure DevOps or Bitbucket — you'll pay twice and maintain two YAML dialects | Playwright or Cypress for E2E tests — actions/upload-artifact stores run videos directly in the workflow summary |
| Team is fewer than 50 developers and you want zero CI server administration overhead | You need complex multi-repo orchestration or DAG-style pipelines — Jenkins or Tekton handle those patterns better | Snyk — add the snyk/actions security scan job so every PR gets a vulnerability report without a separate CI login |
| You need matrix builds across multiple OS or language versions (e.g. Node 18/20/22 on Ubuntu and Windows simultaneously) | Compliance requires all build infrastructure to stay on-premises with no internet egress — self-hosted runners help but add complexity | Docker — build and push images inside the workflow using docker/build-push-action, keeping image provenance tied to the commit SHA |
| Your team ships to multiple cloud targets (AWS, Azure, GCP) and wants one configuration file per environment | You have a large Jenkins estate with thousands of existing pipelines — migration cost outweighs the benefits for most organisations | Terraform — trigger plan/apply steps after tests pass, so infrastructure and code ship in the same atomic workflow |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
.github/workflows/test.yml that runs the existing test suite on pull requests, prove the green-to-green parity, then pitch the broader migration. Don't ask for a big-bang rewrite; show the win on something small that nobody will miss if it breaks for a day.actions/upload-artifact, and merge reports in a final job. This typically cuts runtime to under 8 minutes at no additional tooling cost. The YAML is maybe 30 lines. Do this before evaluating paid parallelisation services like Buildkite.on: schedule: cron: '0 22 * * *' (10 pm NZST), store staging credentials as encrypted GitHub repository secrets rather than in the YAML, and configure the workflow to post a Slack summary via slackapi/slack-github-action when the run fails. Never commit API keys — even test ones — directly into workflow files; secrets rotation after an accidental commit costs more time than setting it up correctly from the start.The bottom line: GitHub Actions earns its place when your code already lives in GitHub — adding a separate CI platform is a second thing to maintain, a second place to debug, and a second login to manage. Start with the workflow file, not the platform decision.
Interview questions
Questions you are likely to get if you list GitHub Actions on your CV — with what interviewers are really testing for.
What is the difference between a job and a step in a GitHub Actions workflow, and why does it matter for test pipelines?
What they’re really testing: Whether you understand the execution model well enough to design pipelines, not just copy-paste YAML from documentation.
Strong answer covers: Jobs run on separate runners (fresh environment each time, run in parallel by default); steps share the same runner and file system within a job. Explain that for a QA pipeline you’d put lint, unit tests, and E2E tests in separate jobs so they can run in parallel and fail independently — a unit test failure shouldn’t block the lint report. Mention that needs: lets you sequence jobs when an E2E job genuinely depends on a build job finishing first.
When would you choose GitHub Actions over Jenkins for a NZ government agency that already has a Jenkins instance?
What they’re really testing: Whether you can weigh real trade-offs rather than defaulting to whichever tool you used last — and whether you understand on-premises compliance constraints.
Strong answer covers: For agencies subject to NZISM or handling data classified Restricted and above, build infrastructure often cannot egress to GitHub’s hosted runners — self-hosted runners on GitHub Actions can satisfy this, but Jenkins on-premises is already compliant with no extra configuration. GitHub Actions wins when the agency’s code is already on GitHub and the maintenance burden of the Jenkins instance outweighs the compliance effort; Jenkins wins when the existing pipeline estate is large and migration cost is prohibitive. Always frame it as a cost/risk/compliance analysis, not a technology preference.
You’re a QA engineer at a Wellington fintech. Your Playwright tests pass on your laptop but fail consistently in the GitHub Actions runner. Walk me through how you’d diagnose that.
What they’re really testing: Systematic debugging under CI-specific constraints — can you isolate environment differences without being able to SSH into the runner?
Strong answer covers: First, check the runner OS and browser version against your local setup — GitHub-hosted Ubuntu runners use a specific Chromium build that may differ from yours. Add --debug output and use actions/upload-artifact to capture Playwright trace files and screenshots on failure. Check for timing issues caused by slower runner I/O by increasing timeouts temporarily. Verify environment variables (base URL, credentials) are being injected from GitHub Secrets and not defaulting to localhost values. Rule out network-dependent tests failing because the runner can’t reach an internal staging server.
How would you structure a GitHub Actions workflow to handle secrets safely for a nightly regression suite running against a staging environment?
What they’re really testing: Security hygiene around credentials — a common source of breaches, and a signal that you treat test environments as seriously as production.
Strong answer covers: Store all credentials as encrypted GitHub repository or environment secrets, never in the YAML file or checked into source control. Reference them in the workflow as ${{ secrets.STAGING_API_KEY }}. Use GitHub Environments with required reviewers for production deployments so secrets are scoped and an approval gate exists. Explain that under the Privacy Act 2020, test data containing personal information must not appear in logs — use add-mask to redact sensitive values from workflow output. Rotate secrets immediately if a YAML file is ever accidentally committed with a hard-coded value.
How would you architect a GitHub Actions pipeline for a NZ SaaS product that needs to run fast on pull requests but thorough on merges to main?
What they’re really testing: Whether you understand the difference between speed and thoroughness and can design a tiered quality gate — not just whether you know GitHub Actions syntax.
Strong answer covers: Use on: pull_request to trigger a fast pipeline (lint, unit tests, smoke E2E tests — target under 5 minutes) so developers get rapid feedback without blocking their branch. Use on: push: branches: [main] to trigger the full suite (integration, full E2E, security scan, accessibility checks) after merge. Use matrix builds to cover the browser and OS combinations that matter for your NZ user base. Add a scheduled cron workflow for nightly extended regression against staging so long-running test suites don’t slow the daytime PR cycle at all.