Features & Capabilities

This page describes every function the Copilot GitHub Action provides: workflow-triggered behavior (issues, pull requests, pushes) and single actions you can run on demand.

Workflow-triggered behavior

The action is typically invoked by three workflow triggers. What it does depends on the event.

1. Issue events (on: issues)

When the workflow runs on issues (opened, edited, labeled, unlabeled, etc.):

2. Pull request events (on: pull_request)

When the workflow runs on pull_request (opened, edited, etc.):

3. Push events (on: push)

When the workflow runs on push (e.g. to any branch):

Single actions

When you set single-action (and, when required, single-action-issue, single-action-version, single-action-title, single-action-changelog), the action runs only that action and skips the normal issue/PR/push pipelines.

Single actions that throw an error if the last step fails: publish_github_action, create_release, deployed_action, create_tag. This lets the workflow fail the job when the action does not succeed.

AI features (OpenCode)

All AI features go through OpenCode (one server URL + model). You can use 75+ providers (OpenAI, Anthropic, Gemini, Ollama, etc.) by configuring OpenCode.

Configuration: opencode-server-url, opencode-model, and optionally opencode-start-server (action starts and stops OpenCode in the job). For bugbot autofix, use bugbot-fix-verify-commands to list commands to run after fixes (e.g. npm run build, npm test, npm run lint). See Bugbot and OpenCode (AI).

Workflow concurrency and sequential execution

GitHub's native concurrency lets you cancel in-progress runs when a new one starts (cancel-in-progress: true). Copilot adds sequential execution for the same workflow: when a new run starts, the action waits for any previous run of the same workflow name to finish before doing its work.

How it works

1. At the start of each run (except welcome/single-action-only flows), the action calls the GitHub API to list workflow runs for the repo.
2. It filters runs that have the same workflow name as the current run, a lower run ID (i.e. started earlier), and status in_progress or queued.
3. If any such run exists, the action waits 2 seconds and checks again, up to a long timeout (~4000 seconds).
4. When no previous run of the same workflow is active, the action continues.

So you get a per-workflow queue: multiple triggers for the same workflow (e.g. many issues labeled at once) will run sequentially.

Example

name: Copilot - Issue

on:
  issues:
    types: [opened, edited, labeled, unlabeled]

jobs:
  copilot-issues:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: vypdev/copilot@master
        with:
          token: ${{ secrets.PAT }}
          project-ids: '2,3'

If you prefer to cancel the previous run when a new one is triggered (e.g. for PRs, so only the latest run matters), use cancel-in-progress: true and the same concurrency.group per PR or issue.

Other capabilities

• Commit prefix transforms: commit-prefix-transforms defines how branch names are turned into commit prefixes (e.g. replace-slash, kebab-case). Used for validation and comments.
• Issue types: Configurable issue type names, descriptions, and colors (Task, Bug, Feature, Documentation, Maintenance, Hotfix, Release, Question, Help).
• Debug: Set debug: true for verbose logging.

For full input reference, see Configuration.