/pr-checklist

name: pr-checklist
description: Use when opening or finalizing a GitHub PR for OpenMetadata. Walks through the repo PR template — linked issue, high-level design (for big PRs), unit/integration/Playwright tests + coverage, UI screen recording, and manual test steps — then drafts a fully-filled PR body and (optionally) creates the PR.
user-invocable: true
argument-hint: "[branch name or PR number — defaults to current branch]"

PR Checklist for OpenMetadata

Walks through `.github/pull_request_template.md` section by section, gathers evidence, and produces a fully-filled PR description before creating the PR.

When to Use

• Before running `gh pr create`
• After finishing implementation, before requesting review
• Updating the description of an existing PR that's missing required sections

Usage

/pr-checklist                    # Walk template for current branch vs origin/main
/pr-checklist feature-branch     # Same, for a different branch
/pr-checklist 12345              # Update description of an existing PR

Required Sections (from `.github/pull_request_template.md`)

Every PR must address each section below. Skip with an explicit "Not applicable — <reason>" rather than leaving blank.

1. **Linked issue** — `Fixes #<issue-number>` (GitHub auto-links). No issue → open one first. A test fix needs none (see Step 2). 2. **Type of change** — exactly one box checked. 3. **High-level design** — required for large PRs (new features, refactors, breaking changes, >5 files); skip for small bug fixes. 4. **Tests** — use cases covered, unit tests + coverage %, backend integration tests, ingestion integration tests, Playwright (UI) tests, manual test steps. 5. **UI screen recording / screenshots** — required for any UI change. 6. **Checklist** — every box either checked or explicitly N/A.

Step-by-Step Workflow

Step 1 — Inspect the change

git status
git diff origin/main...HEAD --stat
git log origin/main..HEAD --oneline

Use the diff to classify the PR:

• **Touches `openmetadata-ui/src/main/resources/ui/`** → UI change (recording required).
• **Touches `openmetadata-service/`** + new/changed REST endpoints → backend integration tests required.
• **Touches `ingestion/src/metadata/ingestion/source/`** → ingestion tests required.
• **>5 files changed, or new feature / refactor / breaking change** → high-level design required.
• **Single-file fix with obvious scope** → small change, design section can be `N/A`.

Step 2 — Confirm the linked issue

Ask the user for the issue number if not obvious from the branch name or commit messages. Verify it exists:

gh issue view <issue-number>

If no issue exists, stop and ask the user to open one before continuing.

**Exception: a test fix needs no issue.** Don't file an issue for a PR whose purpose is to fix a failing or flaky test. That holds even when the fix lands in the code the test caught rather than in the test itself. For such a PR:

• Replace the template's `Fixes #<issue-number>` line with the test it fixes, e.g. `Fixes the ChartResourceIT.test_bulkCreateOrUpdate_mixedCreateAndUpdate flake`.
• Give it a descriptive title with no issue number.
• Add the `skip-pr-checks` label. "Validate PR Metadata" fails any PR without a linked issue, and this label is the only thing that skips it.

Step 3 — Gather test evidence

Run the relevant commands and capture output. Don't fabricate coverage numbers — run the tools.

**Backend (Java):**

mvn test -pl openmetadata-service -Dtest=<ChangedTestClass>
mvn jacoco:report -pl openmetadata-service
# Coverage HTML: openmetadata-service/target/site/jacoco/index.html

**Backend integration tests:**

mvn test -pl openmetadata-integration-tests -Dtest=<NewIT>

**Ingestion (Python):**

source env/bin/activate
cd ingestion
make unit_ingestion_dev_env
python -m pytest tests/unit/<changed_path>/ --cov=metadata.<module> --cov-report=term-missing

**Frontend unit tests (Jest):**

cd openmetadata-ui/src/main/resources/ui
yarn test <ChangedComponent> --coverage

**Playwright (UI E2E):**

cd openmetadata-ui/src/main/resources/ui
yarn playwright:run --grep "<feature name>"

For each, note the actual coverage % and test file paths in the PR body.

> Tip: hand off the heavy lifting — `/test-enforcement` produces the same evidence and enforces 90% coverage on changed classes. Run it first if the user hasn't already.

Step 4 — Collect manual test steps

Ask the user (or recall from the conversation): "What did you do by hand to verify this works?" List concrete, reproducible steps:

• Stack started (`./docker/run_local_docker.sh -m ui -d mysql`)
• Login user / role
• Click path through the UI
• Sample input + observed output
• Negative-path check (error case, permission denial)

Step 5 — UI screen recording (UI changes only)

If the PR touches the UI, the recording is **required**. Tell the user:

• macOS built-in: `Cmd+Shift+5` → "Record Selected Portion"
• Save as `.mov`, drag-and-drop into the PR description (GitHub uploads it inline)
• Include before/after screenshots for visual changes (toolbar, layout, color)

If the user can't attach the recording yet, mark the section `TODO: attach recording` and don't open the PR until it's added — or open as draft.

Step 6 — Draft the PR body

Fill in `.github/pull_request_template.md` with everything gathered above. Show the user the full draft for review before creating.

Step 7 — Create or update the PR

**New PR** (use a HEREDOC so formatting survives):

gh pr create --base main --title "Fixes #<issue>: <short title>" --body "$(cat <<'EOF'
<filled-in template here>
EOF
)"

**New test-fix PR** (no issue): use a descriptive title and add `--label skip-pr-checks`.

**Update existing PR**:

gh pr edit <number> --body "$(cat <<'EOF'
<filled-in template here>
EOF
)"

Return the PR URL when done.

Quality Gates Before Creating the PR

Refus