GitHub ActionsWhat is GHAWorkflow SyntaxSecrets & OIDCMatrix BuildsReusableProductionTroubleshootInterview Q&ARoadmap
⚡ What is GitHub Actions?
›GitHub Actions is CI/CD built directly into GitHub. No separate server. No Jenkins to manage. You write a YAML file, push it to your repo, and GitHub automatically runs your pipeline on every push, PR, or schedule.
Core Concept
Event happens (push to main) → Workflow triggers → Jobs run in parallel on separate VMs → each Job has Steps that run in sequence.
| Concept | What it is | Runs |
|---|---|---|
| Workflow | YAML file in .github/workflows/ | When event triggers it |
| Event | push, pull_request, schedule, manual | Triggers the workflow |
| Job | A set of steps running on one machine | In parallel with other jobs (default) |
| Step | One command or one reusable action | In sequence inside a job |
| Action | Reusable step from GitHub Marketplace | Inside a step |
| Runner | The VM that runs a job | ubuntu-latest, windows, macOS or self-hosted |
GitHub Actions vs Jenkins
| GitHub Actions | Jenkins | |
|---|---|---|
| Infrastructure | GitHub manages everything | You manage servers + agents |
| Setup time | Minutes — just write YAML | Hours — install, configure, plugins |
| Scaling | Automatic — GitHub adds runners | Manual — add more agents |
| Cost (small teams) | Free 2000 min/month | Free but server costs |
| Best for | GitHub repos, new projects, teams that don't want infra overhead | Complex pipelines, existing enterprise, full control |
How GitHub Actions works
📄 Workflow Syntax — Complete Reference
›Every workflow lives in .github/workflows/filename.yml. You can have multiple workflows — one for CI, one for releases, one for nightly scans.
Complete workflow with all features
🔒 Secrets, Environments & OIDC
›Why Secrets Management Matters
Hardcoding passwords or API keys in YAML files is dangerous — they are visible to everyone with repo access and permanently in Git history. GitHub Secrets encrypts values and automatically masks them in logs.
Three Levels of Secrets
| Level | Where stored | Accessible to | Use for |
|---|---|---|---|
| Repository secrets | Repo → Settings → Secrets | All workflows in this repo | Most secrets |
| Environment secrets | Repo → Settings → Environments | Only jobs using that environment | Prod vs staging values |
| Organisation secrets | Org → Settings → Secrets | Multiple repos | Shared credentials across repos |
OIDC — The Gold Standard (No Stored Credentials)
Instead of storing AWS/Azure/GCP access keys (which expire, get leaked, need rotation), OIDC lets GitHub prove its identity to cloud providers. GitHub gets a short-lived token per run — automatically. Nothing to rotate, nothing to store, nothing to leak.
Secrets and OIDC examples
🧮 Matrix Builds — Test Multiple Versions
›What is Matrix Strategy?
Instead of writing 6 separate jobs to test Python 3.9/3.10/3.11 on Ubuntu/Windows, define one job with a matrix. GitHub runs all combinations in parallel. If one fails, you know exactly which combination broke.
Matrix builds
📦 Reusable Workflows
›The Problem: Pipeline Duplication
50 microservices, each with their own deploy workflow. Someone updates the deploy pattern — now you update 50 files. Reusable workflows solve this: define once, call from anywhere.
Reusable workflow pattern
🚀 Production Pipeline
›Complete production pipeline with quality gates, security scanning, staging deployment, approval gate, and production deployment.
Full production pipeline
🔍 Troubleshooting & Optimisation
›Most Common Issues
| Problem | Cause | Fix |
|---|---|---|
| Workflow not triggering | Wrong branch name, YAML syntax error | Check branch filter, validate YAML online |
| Resource not accessible | Missing permissions block | Add correct permissions (contents, packages, id-token) |
| Secret not found | Secret not added to repo or wrong name | Check Settings → Secrets → Actions |
| Works locally, fails in CI | Tool not installed on runner | Add explicit setup steps for tools |
| Running out of free minutes | No caching, no conditionals | Add actions/cache, add path filters, use self-hosted runners |
Debug + caching strategies
🎯 Interview Questions
›GITHUB ACTIONS · ENGINEER
What is GitHub Actions and how is it different from Jenkins?
GitHub Actions is CI/CD built directly into GitHub — no server to manage, no plugins to update, no agents to configure. You write YAML workflows stored in .github/workflows/. When an event happens (push, PR, schedule), GitHub automatically runs the workflow on hosted servers (runners). Key differences from Jenkins: GitHub manages all infrastructure — you never think about agents going offline or Jenkins master running out of memory. GitHub Actions uses OIDC for cloud authentication, so no long-lived secrets stored anywhere. The free tier gives 2000 minutes/month which is enough for most projects. Jenkins gives more control and is better for complex pipelines with many dependencies, but GitHub Actions wins for simplicity and GitHub-integrated projects.
GITHUB ACTIONS · ENGINEER
Explain the difference between jobs and steps in GitHub Actions.
Jobs run in parallel by default on separate runner machines. Each job gets a fresh VM — nothing carries over between jobs unless you explicitly pass outputs or use artifacts. Steps run in sequence inside a job on the same machine. If a step fails, the job fails and remaining steps are skipped (unless you add if: always()). Common pattern: quality job (tests, SonarQube) runs in parallel with security job (Trivy, Checkov). Both must pass before the build job starts. Build job produces a Docker image, uploads it as an artifact. Deploy job downloads that artifact and deploys. The needs keyword creates a dependency graph between jobs.
GITHUB ACTIONS · ARCHITECT
How do you manage secrets securely in GitHub Actions?
Three layers. Repository secrets (Settings → Secrets → Actions) for most secrets — these are encrypted and masked in logs. Environment secrets for environment-specific values (prod DB host vs dev DB host). The production environment can require review approval before secrets are accessible, preventing accidental prod deployments. OIDC for cloud providers — instead of storing AWS/Azure keys as long-lived secrets, configure GitHub as an OIDC provider in your cloud account. The workflow requests a short-lived token at runtime using id-token: write permission. No credentials stored anywhere. Rotation happens automatically. At HPE: we moved from AWS access keys in secrets to OIDC — eliminated an entire class of credential rotation toil and security risk.
GITHUB ACTIONS · PRODUCTION
A GitHub Actions workflow is passing locally but failing in CI. Walk through diagnosis.
Systematic approach: First, enable debug logging by adding ACTIONS_RUNNER_DEBUG=true as a repository secret and re-running. The detailed logs usually reveal the exact problem. Common causes: 1) Environment difference — local machine has tools installed globally (kubectl, helm, node) that the runner does not have. Fix: add explicit setup steps (actions/setup-node, actions/setup-java). 2) Secret not set — the workflow references a secret that exists in your environment but not in GitHub. Check Settings → Secrets. 3) Permissions — runner cannot push to registry or create releases. Check permissions block in workflow YAML. 4) Path difference — workflow runs from repo root, local you run from a subdirectory. Use working-directory: ./subfolder. 5) Token scope — GITHUB_TOKEN has limited permissions. Check if you need additional permissions.
GITHUB ACTIONS · ARCHITECT
How do you design a GitHub Actions workflow for multiple environments with approval gates?
Use GitHub Environments with protection rules. Create three environments in repo Settings → Environments: staging (no approvals, auto-deploy), uat (1 required reviewer), production (2 required reviewers + branch protection). Each environment can have its own secrets (prod DB password different from staging). In the workflow, set environment: production on the deployment job. GitHub automatically pauses the workflow and sends notifications to required reviewers. If they approve, the workflow continues. If they reject or timeout (configurable), the workflow fails. This gives a complete audit trail — who approved what deployment, when, and from which commit. No Slack messages that disappear, no email threads. All in GitHub history.
GITHUB ACTIONS · ENGINEER
What are reusable workflows and when should you use them?
Reusable workflows are workflow files that other workflows can call — like functions. You define them once with workflow_call trigger and inputs/secrets parameters. Any other workflow calls them with uses: org/repo/.github/workflows/deploy.yml. Use them when: multiple repos do the same deployment pattern (all microservices deploy to Kubernetes the same way), you want to enforce standards (all deployments must include security scan before push), or you want to simplify individual repo workflows (50-line workflow becomes 10 lines calling reusable workflows). Difference from composite actions: reusable workflows run as separate jobs. Composite actions are steps within a job. Reusable workflows are better for complete deployment flows; composite actions for step-level reuse.
GITHUB ACTIONS · PRODUCTION
GitHub Actions minutes are being used too quickly. How do you optimise?
Measure first: Actions → billing shows minutes per workflow. Four main optimisations. One: caching — use actions/cache for node_modules, Maven .m2, pip cache. Saves 2-5 minutes per run. Use hashFiles() to invalidate cache only when dependency files change. Two: parallel vs sequential — check if jobs that run sequentially could run in parallel (needs removed). Three: conditional jobs — skip deployment jobs on PR (if: github.event_name == push). Skip tests on documentation-only changes using paths-ignore or path filters. Four: self-hosted runners — for heavy workloads, run on your own server. No minute counting. Your server, your hardware. Good for Docker builds with large images (10+ GB) where network bandwidth to GitHub runners is the bottleneck.
GITHUB ACTIONS · ARCHITECT
How does OIDC authentication work in GitHub Actions?
OIDC (OpenID Connect) lets GitHub Actions authenticate to cloud providers without stored credentials. Traditional approach: store AWS access key ID and secret in GitHub secrets. Problem: long-lived credentials, manual rotation, risk of exposure. OIDC approach: GitHub acts as an identity provider. When a workflow runs, GitHub mints a short-lived JWT token signed by GitHub's private key. Your cloud provider (AWS, Azure, GCP) is configured to trust GitHub's identity provider. The workflow exchanges the GitHub JWT for a cloud-specific credential. The cloud credential expires after 1 hour. Setup: AWS IAM console → Identity providers → Add GitHub as OIDC provider. Create an IAM role with condition that allows only your specific repo/branch. Add permissions: id-token: write to workflow. Use aws-actions/configure-aws-credentials action. Result: no secrets to rotate, no stored credentials, automatic short-lived tokens per run.
🗺️ Roadmap
›Day 1
First Workflow
Create .github/workflows/ci.yml
Trigger on push, run a test
See it run in Actions tab
Week 1
Core Features
Build + push Docker image to GHCR
Store and use secrets
Cache dependencies
Pass outputs between jobs
Week 2
Production Patterns
Environment protection rules + approvals
OIDC for AWS/Azure — no stored keys
Matrix builds
Reusable workflows
Month 2
Architect Level
Self-hosted runners on Kubernetes
Composite actions
Advanced caching strategies
GitHub Apps for org-wide automation
Continue Learning