Microsoft GitHub Actions

A workflow that runs at the wrong time is noise, and one that never runs is a gap. You configure triggers for pushes, pull requests, schedules and manual runs, and narrow them with filters.

• Push and pull request events
• Branch, tag and path filters
• Scheduled workflows
• Manual runs with inputs
• Calling one workflow from another
• Triggering from outside with repository dispatch

You build A set of workflows triggered by pull requests, a nightly schedule and a manual run with inputs.

Real pipelines have order, branches and limits. You chain jobs with dependencies, add conditions, run matrices of versions and systems, and control concurrency and timeouts.

• Job dependencies with needs
• Conditions on jobs and steps
• Matrix builds across versions and systems
• Concurrency groups and cancelling runs
• Timeouts and continuing on error
• Containers and service containers

You build A multi-job pipeline that tests across a matrix and deploys only when everything passes.

Steps and jobs run in isolation, so data must be passed on purpose. You use contexts and expressions, step and job outputs, artifacts and caches, and learn which to use for which kind of data.

• Contexts and expressions
• Environment variables and default variables
• Step outputs and job outputs
• Uploading and downloading artifacts
• Caching dependencies between runs

You build A workflow that builds in one job, passes the result to another as an artifact and caches dependencies.

Copying YAML between repositories creates drift. You build reusable workflows with inputs and secrets, call them from other workflows, and publish starter workflows so teams begin from a good default.

• Writing a reusable workflow
• Inputs, secrets and outputs of a called workflow
• Calling reusable workflows across repositories
• Starter workflows for an organization
• Versioning shared workflows

You build A reusable build-and-test workflow consumed by two repositories, plus a starter workflow.

Most of the time spent on Actions goes to red builds. You read run logs, turn on debug logging, use annotations and artifacts as evidence, and find the cause rather than re-running until it passes.

• Reading a run’s logs and summary
• Debug logging for steps and runners
• Annotations, summaries and status checks
• Finding and downloading artifacts from a run
• Re-running failed jobs sensibly
• Common failure patterns and their causes

You build A diagnosis of three broken workflows, each with its cause and fix written up.

When a script is reused, it deserves to be an action. You build JavaScript, Docker container and composite actions, and learn which type suits which job and how each runs.

• JavaScript actions and the toolkit
• Docker container actions
• Composite actions that bundle steps
• Inputs, outputs and exit codes
• Testing an action inside a workflow
• Troubleshooting an action that misbehaves

You build The same small task built as a composite action and as a JavaScript action, with notes on the trade-offs.

An action other people depend on needs a stable contract. You write its metadata, document it, release and tag versions, and publish to the Marketplace or keep it private for your organization.

• The action metadata file
• Documenting inputs and outputs
• Release tags and major version tags
• Publishing to the Marketplace
• Private actions for an organization
• Handling breaking changes

You build A versioned action with metadata and documentation, released with a major version tag.

At scale, Actions is shared infrastructure with rules. You choose between hosted and self-hosted runners, group and label them, control which actions may run, and share workflows across the enterprise.

• GitHub-hosted and self-hosted runners compared
• Runner groups and labels
• Registering and maintaining self-hosted runners
• Policies for allowed actions and workflows
• Sharing actions and workflows inside an enterprise

You build A runner and policy design for an enterprise with one team that needs private network access.

Pipelines need credentials, and credentials leak. You store secrets and variables at the right level, use environments with approvals, and replace long-lived keys with short-lived tokens from your cloud provider.

• Secrets and variables at repository, organization and environment level
• Environments and required reviewers
• Protection rules for deployments
• OpenID Connect to reach a cloud provider without stored keys
• Secret handling in logs and forks

You build A deployment workflow with an approval-protected environment and cloud access through short-lived tokens.

A workflow runs code with real permissions, so it is an attack surface. You limit the GITHUB_TOKEN, prevent script injection from untrusted input, and treat third-party actions as dependencies to pin and review.

• Least-privilege permissions for GITHUB_TOKEN
• Script injection from issue titles and branch names
• Risks of workflows triggered by forks
• Pinning third-party actions to a commit
• Keeping action dependencies updated
• Auditing a workflow for risk

You build A security review of a vulnerable workflow, with each flaw demonstrated and then fixed.

Slow and wasteful pipelines cost developers time and the company money. You cut run time with caching and filters, size runners to the work, and set retention that keeps what you need and drops the rest.

• Finding the slow step
• Caching and path filters
• Concurrency to avoid wasted runs
• Choosing runner sizes
• Retention for logs and artifacts
• Reading usage and billing for Actions

You build A before-and-after optimization of a slow pipeline, with the time and usage change measured.

One pipeline joins the course. You author the workflows, share them as reusable parts, build a custom action, secure it all, and set the policies and runners an organization would need.

• Designing the pipeline for a sample product
• Authoring and sharing the workflows
• Adding a custom action
• Securing secrets, tokens and dependencies
• Setting enterprise policies and reviewing the result

You build A complete, secured delivery pipeline for a sample project, with shared workflows and enterprise policy.