Skip to content

[quality] PR #555 merge-queue auto-merge needs hold-label guard #560

Description

@clubanderson

Finding

PR #555 introduces auto-merge on lgtm label via on-pr-lgtm job in the lifecycle workflow. The job runs gh pr merge --auto when the lgtm label is applied to any PR.

Critical gap: There is no guard against accidentally auto-merging PRs that have hold, status/hold, or do-not-merge labels. If a maintainer adds lgtm to a held PR (e.g. "looks good but not yet"), the PR enters the merge queue immediately.

Additionally:

  • The merge_group trigger added to unit-tests.yml has no dry-run validation
  • There's no test confirming the lifecycle workflow's label conditions behave correctly
  • No documentation of the expected label interaction matrix (lgtm + hold = ?)

Recommendation

  1. Add a label guard to the on-pr-lgtm job:
    - name: Check for hold labels
      run: |
        LABELS=$(gh pr view "$NUMBER" --repo "$REPO" --json labels -q '.labels[].name')
        for block in "do-not-merge" "status/hold"; do
          echo "$LABELS" | grep -q "$block" && { echo "Blocked by $block"; exit 0; }
        done
  2. Add a workflow validation test (can use act or a simple YAML schema check)
  3. Document the label interaction matrix in CONTRIBUTING or AGENTS.md

Priority

  • Impact: high (could auto-merge held/blocked PRs)
  • Effort: low (single conditional check in workflow)

Filed by quality agent (hold-gated mode)

Common · issue pipeline

  ▶  triage     needs kind/ + area/ then /approve
  ·  discussing —
  ·  queued     —
  ·  claimed    —
  ·  done       —

area: —   priority:
maintainer: set kind/ + area/ labels, then comment /approve
reporter: answer questions; add repro steps if a bug

Metadata

Metadata

Assignees

No one assigned

    Labels

    1-triageNew work awaiting human triage.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions