GitHub Actions, Copilot, Codespaces and github.dev: Automation and AI Tools (GH-900)

GitHub Actions is GitHub's built-in automation platform: it runs a workflow of jobs on a machine whenever a chosen event happens in a repository. The best-known use is continuous integration and continuous delivery (CI/CD) — build and test every push or pull request, then deploy or publish — but Actions is not limited to code pipelines. Because almost anything on GitHub can be an event, a workflow can also automate repository housekeeping.

Typical uses:

• Test pull requests: a workflow triggered by the pull_request event runs the test suite, and the result appears as a check on the pull request before anyone merges it.
• Build and publish: a workflow triggered when a release is published builds a package or container image and pushes it to a registry.
• Repository automation: a workflow triggered when an issue is opened adds a label, posts a welcome comment or adds the issue to a project.
• Scheduled jobs: a schedule trigger (cron syntax) runs a workflow at fixed times — for example a nightly link check — whether or not anyone pushed that day.
• Manual runs: a workflow_dispatch trigger adds a Run workflow button.

Actions is the tool that runs automation. It is not where a person edits code (that is Codespaces or github.dev), it does not suggest code (that is Copilot), and it does not track work (that is Projects).

Workflow vocabulary: events, workflows, jobs, steps, actions and runners

An Actions workflow is a chain of six terms, and each one has a precise meaning:

Two rules are worth knowing exactly:

• Location: GitHub only runs workflow files committed under .github/workflows. Other folders have other jobs — .github/ISSUE_TEMPLATE holds issue templates and .devcontainer configures codespaces.
• Job order: jobs have no dependencies unless you declare them, so by default they run in parallel, each on its own runner. To make one job wait for another, declare it with needs:. The order of jobs in the file does not set their order. Steps, by contrast, always run one after another within their job.

on: pull_request
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm run lint

In this workflow, build and lint start at the same time on two separate runners; within each job the steps run top to bottom.

Use a GitHub-hosted runner when you want GitHub to supply and maintain the machine, and a self-hosted runner when the job needs an operating system, hardware or network access that GitHub's machines do not provide.

GitHub also offers larger runners — GitHub-hosted machines with more CPU and memory — but they are still GitHub's machines, not yours.

Billing follows two rules. Standard GitHub-hosted runners are free in public repositories. In private repositories, the account's plan (including GitHub Free) includes a monthly quota of minutes and storage; usage beyond the quota is billed, subject to the account's spending limits. The plan does not make private usage free, and a public repository does not consume the quota. Self-hosted runners do not use the minutes quota at all.

GitHub Copilot is an AI pair programmer, and its most basic feature is inline code suggestions: as you write, Copilot reads the context around the cursor and offers the rest of the line or a whole block as dimmed ghost text. There are two ways to prompt it without opening chat:

• Start typing code — Copilot completes the line, function or block you have begun.
• Write a comment that describes the logic, then start the next line — Copilot proposes code that implements the comment.

In VS Code you accept a suggestion with Tab, reject it with Esc, and step through alternative suggestions with Alt+] and Alt+[ (Option on macOS). Cycling only shows another option; it does not insert anything.

Other Copilot features are not inline suggestions: Copilot Chat answers in a chat panel (for example /explain on a selection), Copilot code review leaves comments when you request Copilot as a pull request reviewer, and assigning an issue to Copilot starts the cloud agent described below.

Suggestions that match public code

Because Copilot learned from public code, a suggestion can occasionally match code in a public repository. A public code policy (set by the individual, or by the organization or enterprise for its members) decides what happens: block suggestions that match public code, or allow them and show references to where the matching code appears so the developer can check its license and decide. The check compares against public repositories on GitHub.com — not private code or code hosted elsewhere.

Copilot Chat in an IDE has modes that differ in how much Copilot does by itself. Agent mode is the one that acts: given a task, it decides which files are relevant, edits code across them, runs terminal commands such as builds and tests, reads the results and keeps iterating to fix errors until the task is done — all inside your IDE, with you able to review and approve.

The deciding question for agent mode versus ask mode is whether Copilot should change files and run commands (agent) or only answer (ask). The deciding question for agent mode versus cloud agent is where the work runs: agent mode needs your IDE session; the cloud agent works on GitHub while nobody has an editor open.

Copilot cloud agent: delegating a task to run in the background

Copilot cloud agent is the Copilot agent that works on GitHub rather than in your editor: you hand it a task, it researches the repository, plans and makes the change in its own ephemeral development environment (powered by GitHub Actions), and delivers the result as a pull request. GitHub's documentation now calls it the cloud agent; you may also see it described as the Copilot coding agent.

• Starting it: assign an issue to Copilot, start a task from the agents panel or a Copilot Chat conversation, or mention @copilot in a comment on a pull request it is working on to have it change that pull request.
• Delivering work: it creates a branch, writes the commits and opens a pull request for the task. It never merges by itself — the pull request goes through the repository's normal review, required checks and branch protection, and you can ask it for changes by commenting.
• Customising its environment: a copilot-setup-steps.yml workflow can preinstall the tools and dependencies the agent needs.

It suits well-scoped work — a bug fix, a small feature, extra tests, documentation updates — that a person would otherwise pick up from the backlog. The pull request is the deliverable: you review it like any other contribution.

Multi-model support means Copilot Chat can use different AI models from several providers, and you choose one per conversation from the model picker in the chat view. Different models trade speed against depth of reasoning, and some draw more heavily on a plan's monthly AI allowance (GitHub AI Credits) than others.

• Auto: instead of a named model, choose Auto and Copilot selects a model for you based on availability, which helps reduce rate limiting.
• Chat only: changing the chat model does not change the model behind inline code suggestions.
• Organization control: on Copilot Business and Copilot Enterprise, administrators decide through policy which models are available; for Copilot Business members, the organization must allow members to switch to other models. An empty model picker for a Business seat therefore points at the organization's policy.

The plan depends first on who buys and manages Copilot. A person buying for themselves uses an individual plan; an organization buying seats for its members uses Copilot Business; an enterprise on GitHub Enterprise Cloud can use Copilot Enterprise.

Points that decide scenarios:

• The exam's "Copilot for Individuals" is today's individual plans. Copilot Free needs no payment; Copilot Pro, Pro+ and Max are paid upgrades with progressively larger allowances. GitHub also gives eligible verified students free access.
• Copilot Pro is not GitHub Pro. GitHub Pro is a personal account plan for GitHub features; it does not buy Copilot.
• Individual plans have no organization-wide policies or content exclusion — those start at Business.
• Enterprise is designed for enterprises using GitHub Enterprise Cloud. Without GHEC, a company that needs central management chooses Business.
• On GitHub Enterprise Cloud, the enterprise owner chooses the plan per organization, so one organization can have Enterprise while another has the lower-priced Business.

A codespace is a cloud-hosted development environment: a Docker container running on a virtual machine that GitHub hosts, with the repository cloned in, a terminal, and the compute to build, run and debug code. Nothing has to be installed locally, so it works from a Chromebook or a borrowed laptop.

You can open a codespace in three ways: in the browser (a VS Code editor), in VS Code desktop, or from a terminal with the GitHub CLI — gh codespace create creates one and gh codespace ssh connects to it (JetBrains IDEs are also supported).

Lifecycle and billing

• Compute is billed only while a codespace is active. Storage is billed for as long as the codespace exists — including while it is stopped.
• Idle timeout: a codespace with no activity stops after a timeout that defaults to 30 minutes. You can change it in your settings (organizations can set a shorter maximum). Stopping is not deleting: files and changes stay.
• Separately, a running codespace has a maximum lifetime of 12 hours; that is not the idle timeout.
• Automatic deletion: stopped codespaces that stay inactive are deleted after a retention period that defaults to 30 days.
• Personal accounts get a monthly quota of free Codespaces usage. To stop unneeded codespaces counting against it right away, delete them — a stopped codespace still uses storage, and a shorter idle timeout only affects running ones.

A dev container configuration is the file that tells Codespaces how to build the container for a repository, so everyone who opens a codespace gets the same tools. It lives at .devcontainer/devcontainer.json (or .devcontainer.json in the repository root), and a repository can offer several configurations in subfolders of .devcontainer.

A devcontainer.json can set:

• the base image, or a Dockerfile or Docker Compose file to build from;
• features — packaged tools and runtimes to add, such as a language version or a CLI;
• VS Code extensions and settings to install for everyone;
• ports to forward, and lifecycle commands such as postCreateCommand to run setup scripts.

{
  "image": "mcr.microsoft.com/devcontainers/javascript-node:20",
  "features": {
    "ghcr.io/devcontainers/features/github-cli:1": {}
  },
  "customizations": {
    "vscode": { "extensions": ["dbaeumer.vscode-eslint"] }
  },
  "forwardPorts": [3000],
  "postCreateCommand": "npm ci"
}

No configuration, and changing it

• No configuration is fine: GitHub builds the codespace from a default Linux image that already includes popular runtimes (for example Python, Node.js and Java) and tools such as Git and GitHub CLI. Add a devcontainer.json when the team needs a specific, repeatable setup.
• Applying a change: an existing codespace does not pick up configuration changes by itself. Run Codespaces: Rebuild Container (or gh codespace rebuild). A rebuild keeps the /workspaces directory, where the repository is cloned, but clears changes elsewhere, such as files in your home directory — move anything you want to keep into /workspaces first. A new codespace does not include files from your other codespaces.

Codespaces separates team configuration, committed to the repository in devcontainer.json and shared by everyone, from personal customisation, which follows one user into every codespace without changing any team repository.

• Dotfiles: keep configuration files (and optionally an install script) in a repository you own — it does not have to be public — and turn it on in your Codespaces settings; GitHub clones it into every new codespace you create. GitHub's docs note that dotfiles do not personalise user-scoped VS Code settings; that is what Settings Sync is for.
• Prebuilds: a prebuild configuration runs a GitHub Actions workflow that builds the codespace for a chosen repository, branch and devcontainer.json, runs the setup commands and saves a snapshot. New codespaces start from that snapshot, so slow dependency installs no longer happen at creation time. Prebuilds use Actions minutes and storage.

github.dev is a free, lightweight VS Code editor that runs entirely in your browser, for quick edits without any compute behind it. Open it by pressing the period (.) key while viewing a repository or pull request on GitHub.com, pressing > to open it in a new tab, or changing github.com to github.dev in the URL. You can edit many files, review a pull request and commit through the Source Control view.

The rule of thumb: start in github.dev for edits, and as soon as the work needs to run something — a build script, tests, a preview server — continue in a codespace (github.dev offers a Continue Working On option for this).