Skip to content

Repository navigation

examples.mdx

Latest commit

 

History

History
285 lines (215 loc) · 11.2 KB

examples.mdx

File metadata and controls

285 lines (215 loc) · 11.2 KB
Raw
title Examples
description Workflow snippets, comment examples, and CLI usage for Bugbot.

Examples

This page provides concrete examples: workflows that enable Bugbot detection and autofix, comment phrases that trigger fixes or do-user-request, and CLI commands for on-demand detection.

Push workflow (with Bugbot)

The Commit workflow runs on push to branches (typically excluding main and develop). If an agent CLI is configured, Bugbot detection runs automatically for issue-linked branches without an open PR. After a PR opens, Commit retains issue progress work and the PR synchronize workflow exclusively owns Bugbot review for each new head.

name: Copilot - Commit

on:
  push:
    branches:
      - '**'
      - '!master'
      - '!develop'

jobs:
  copilot-commits:
    name: Copilot - Commit
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v5
        with:
          persist-credentials: false

      - uses: vypdev/copilot@v3
        with:
          token: ${{ secrets.PAT }}
          project-ids: ${{ vars.PROJECT_IDS }}
          agent-provider: ${{ vars.AGENT_PROVIDER || 'codex' }}
          agent-model-provider: ${{ vars.AGENT_MODEL_PROVIDER || 'openai' }}
          agent-model: ${{ vars.AGENT_MODEL || 'gpt-6-luna' }}
          # Optional: Bugbot-specific
          bugbot-severity: "low"
          bugbot-comment-limit: "20"
          ai-ignore-files: "build/*, dist/*"

No contents: write is needed for detection only; the action only posts comments. For autofix and do-user-request, use the PR review-thread workflow below with contents: write, or an explicitly branch-scoped CLI/workflow execution.

Issue comment workflow (read-only and issue-scoped actions)

Workflows that run on issue_comment support issue-scoped analysis, answers, and finding dismissal. They do not infer a write branch for autofix or do-user-request.

name: Copilot - Issue Comment

on:
  issue_comment:
    types: [created, edited]

jobs:
  copilot-issues:
    name: Copilot - Issue Comment
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v5
        with:
          persist-credentials: false

      - uses: vypdev/copilot@v3
        with:
          token: ${{ secrets.PAT }}
          agent-provider: ${{ vars.AGENT_PROVIDER || 'codex' }}
          agent-model-provider: ${{ vars.AGENT_MODEL_PROVIDER || 'openai' }}
          agent-model: ${{ vars.AGENT_MODEL || 'gpt-6-luna' }}
          ai-ignore-files: build/*
          bugbot-fix-verify-commands: ${{ vars.BUGBOT_AUTOFIX_VERIFY_COMMANDS }}

Note: An issue-only comment never scans open PRs to guess a write branch. Use it for analysis, answers, or dismissal. Run autofix and do-user-request from the intended PR review thread, or from an explicitly branch-scoped CLI/workflow execution.

Pull request review-thread workflow (for autofix)

For replies in a PR review thread, use a workflow on pull_request_review_comment. The event supplies an authoritative PR and head branch. contents: write is required for autofix and do-user-request. A general PR-conversation comment is delivered as issue_comment; this contract treats it as non-branch-authoritative and never scans open PRs to turn it into a write target.

name: Copilot - Pull Request Comment

on:
  pull_request_review_comment:
    types: [created, edited]

jobs:
  copilot-pull-requests:
    name: Copilot - Pull Request Comment
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v5
        with:
          persist-credentials: false

      - uses: vypdev/copilot@v3
        with:
          token: ${{ secrets.PAT }}
          agent-provider: ${{ vars.AGENT_PROVIDER || 'codex' }}
          agent-model-provider: ${{ vars.AGENT_MODEL_PROVIDER || 'openai' }}
          agent-model: ${{ vars.AGENT_MODEL || 'gpt-6-luna' }}
          ai-ignore-files: build/*
          bugbot-fix-verify-commands: ${{ vars.BUGBOT_AUTOFIX_VERIFY_COMMANDS }}

On PR events, the action already has the PR’s head branch from the event, so no “resolve branch from issue” step is needed.

Single action: detect potential problems

To run Bugbot detection on demand (e.g. from a manual workflow run), use single-action: detect_potential_problems_action and single-action-issue. The workflow must check out the branch you want to analyze; the action uses the current checkout.

name: Bugbot - Detect (manual)

on:
  workflow_dispatch:
    inputs:
      issue_number:
        description: 'Issue number'
        required: true
        type: number
      branch:
        description: 'Branch to analyze (default: feature/issue-<issue>)'
        required: false
        type: string

jobs:
  detect:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
        with:
          persist-credentials: false
          ref: ${{ github.event.inputs.branch || format('feature/issue-{0}', github.event.inputs.issue_number) }}

      - uses: vypdev/copilot@v3
        with:
          token: ${{ secrets.PAT }}
          single-action: detect_potential_problems_action
          single-action-issue: ${{ github.event.inputs.issue_number }}
          agent-provider: ${{ vars.AGENT_PROVIDER || 'codex' }}
          agent-model-provider: ${{ vars.AGENT_MODEL_PROVIDER || 'openai' }}
          agent-model: ${{ vars.AGENT_MODEL || 'gpt-6-luna' }}

After the run, findings appear on the issue and, when exact identity is uniquely verified, on one canonical PR for that branch.

CLI: detect potential problems

From the repository root (with PERSONAL_ACCESS_TOKEN in the environment and, if needed, agent CLI environment variables), you can run Bugbot detection locally:

# Require issue number; optional branch (default: current branch)
copilot detect-potential-problems -i 123

# Specify branch explicitly
copilot detect-potential-problems -i 123 -b feature/issue-123

# With an explicit token and debug
copilot detect-potential-problems -i 123 -t $PAT -d

See Smoke tests for full setup (the selected agent CLI, API keys, etc.).

Comment examples: autofix

These are examples of comments that typically trigger Bugbot autofix (fix one or more reported findings). The exact interpretation is done by the configured agent; these are common patterns.

Comment Likely effect
fix it Fix the finding in context (e.g. the one in the thread) or a single obvious finding.
fix all Fix all unresolved findings.
fix the first two Fix the first two findings (order may depend on how they’re listed).
arregla / arregla este Same as “fix it” (Spanish).
please fix the null reference and the off-by-one Fix findings that match those descriptions.
fix finding xyz-123 Fix the finding with id xyz-123 if it exists and is unresolved.

Post read-only review commands on an issue or PR. Post file-changing commands in the intended PR review thread (or use an explicit branch-scoped execution). The action will run only if you own the personal repository or have push/maintain/admin collaborator permission in an organization or personal repository; organization membership alone is insufficient. The write target must also be authoritative.

Comment examples: do-user-request

These are examples of comments that typically trigger do user request (general code change, not tied to a specific finding).

Comment Likely effect
add a unit test for the login function Add tests for the login function.
refactor this to use async/await Refactor the code in context to async/await.
add a README section for installation Add an installation section to the README.
implement the missing validation in the form Add validation logic.
add error handling for the API call Wrap or extend the API call with error handling.

Same permission and workflow requirements as autofix: contents: write plus repository ownership or push/maintain/admin collaborator permission in either an organization or personal repository. Organization membership alone is not enough. Natural-language requests should mention @vypbot; use /copilot implement <request> when you want an explicit command.

Example: overflow summary (detection)

When there are more findings than bugbot-comment-limit, the action adds an overflow section to the PR review summary. For issue-only work, it posts one overflow issue comment. It looks conceptually like this (exact wording may vary):

Additional potential problems (not posted individually)
5 more findings were detected. Consider reviewing the branch locally or increasing bugbot-comment-limit.
Titles: "Possible race in cache", "Unused variable in handler", …

On a PR, you see one review containing at most N inline finding comments and the overflow summary. The canonical Bugbot status still counts all accepted current findings; overflow entries appear without a thread link.

Example: what a finding comment looks like

Each finding is posted as a comment with a title, severity, optional file/line, and description. The body also contains a hidden HTML marker used by the action to update or resolve the finding. As a user you only see the visible part, for example:

Title: Possible null reference in login handler
Severity: medium
Example target file (from the analyzed repository): src/auth/login.ts (line 42) Description: The variable user may be null when passed to validateSession. Consider adding a null check before use.

The action uses the marker to later mark this finding as resolved when the configured agent reports it fixed (e.g. after you or the bot change the code).

Example: current PR status card

The PR conversation contains at most one trusted current-state card. A healthy review with work remaining looks conceptually like this:

Current status: 2 findings require attention on e6089b9.

Action: Review the linked threads or comment /copilot fix all.

fixed, obsolete, and dismissed are clean. open, reopened, and verification-required need attention. unknown and a partial/failed projection fail closed and expose bounded recovery details. A provider or state error can recommend one /copilot recheck after its cause is corrected. Fixed coverage limits instead require manual inspection of omitted items; reduce the relevant scope or restore provider access before rerunning. The limits are not configuration knobs, and repeating the same command against unchanged capped evidence is not useful. A superseded run does not edit this card; the newer head owns the next update.

Next steps