GitHub Actions

What it is

GitHub Actions is GitHub’s built-in CI/CD automation engine. You define workflows as YAML files under .github/workflows/ in your repository; each workflow runs jobs containing steps that execute actions when triggered by repository events.

Why it exists

It keeps automation configuration with the repository. Events such as push, pull_request, and schedule can trigger workflows, and reusable actions make common steps composable.

Key ideas

• Workflow = the automation unit; one YAML file = one workflow.
• Events drive it (push, pull_request, workflow_dispatch, schedule); see ci-trigger.
• Jobs run in parallel by default; steps within a job run sequentially and share a runner’s filesystem.
• Runners execute jobs — GitHub-hosted (ubuntu/windows/macos) or self-hosted.
• Actions are reusable building blocks (community or actions/* official).
• Artifacts — actions/upload-artifact / actions/download-artifact share build output between jobs; see build-artifact.
• Reusable workflows & composite actions enable reuse; see pipeline-templates.

Exam notes

• Workflow file lives at .github/workflows/<name>.yml.
• GitHub-hosted and self-hosted runners have different security, maintenance, and billing considerations. Check the current GitHub plan and runner documentation before estimating cost.
• A workflow that deploys to Azure needs an appropriately scoped Azure identity and authorization; do not put a long-lived credential in the workflow file.
• Runs (like Azure Pipelines runs) are the execution of a workflow on an event.

Related

azure-pipelines · ci-trigger · build-artifact · pipeline-templates · self-hosted-agent

📘 Source: GitHub Docs — Workflows and workflow artifacts, checked 2026-09-17.