Skip to main content
Automating your CI/CD pipelines with GitHub Actions starts with understanding its three building blocks: workflows, jobs, and steps. In this guide, we’ll break down each component, show examples, and highlight best practices for scalable, maintainable pipelines.

1. Workflow

A workflow is a YAML-defined automation triggered by repository events (such as push, pull_request, or scheduled events). You store workflows in the .github/workflows directory of your repo.
Workflows must reside in .github/workflows; files ending with .yml or .yaml will be automatically detected.
Key workflow fields:

2. Job

A job is a sequence of steps that run on the same runner. Jobs execute in isolation, so artifacts and environment variables are not shared unless you explicitly pass them.
  • runs-on: Specifies the runner environment (GitHub-hosted or self-hosted).
  • Jobs can run in parallel by default, or you can enforce a sequence using needs.
By default, each job runs in a clean VM/container. Use needs to share artifacts or enforce order.

3. Steps

Steps are individual tasks executed within a job. They run sequentially on the job’s runner and support two main modes:
  • Actions (uses:) – Reusable extensions from GitHub Marketplace or your own.
  • Commands (run:) – Inline shell commands.
Example steps:

You can extend your workflows with first-party or community actions. Here are a few commonly used ones:
The image outlines a three-step GitHub Actions process: building and pushing Docker images, creating an AKS cluster, and consuming Vault secrets.

Component Comparison


Next Steps

Now that you’ve seen how workflows, jobs, and steps interact, let’s create your first GitHub Actions workflow from scratch:
Commit and push to trigger your first automation run.

References

Watch Video