Create Fix PR

Create Fix PR

Opens a GitHub pull request for the CVE fix already applied in REPO_DIR (Phase 5). Never commits, pushes, or opens a PR without explicit approval — interactive, or AUTO_APPROVE=yes recorded once upfront (see Autonomous Mode). Direct CVE mode (no --jira=/--jql=) still creates the PR; it just omits Jira Fixes: links and the Jira follow-up comment.

Called from Phase 6 of the analyze-cve skill after Phase 5 verification succeeds.

When to Use This Skill

Use this skill when:

• Phase 5 applied a fix in REPO_DIR and verification passed
• The user approved creating a GitHub PR
• embargo_status is not True

Do not use this skill to apply the fix itself (that is Phase 5) or to post the analysis report (that is report-to-jira in Phase 4).

Required Inputs

From the parent command:

Prerequisites

Hard requirements for this skill. Phase 0 does not treat gh as required (warn-only). This skill must not assume either tool is present — re-check both, then fail if either is missing. Do not create a PR another way.

which git 2>/dev/null || echo "MISSING: git"
which gh 2>/dev/null || echo "MISSING: gh"
gh auth status 2>/dev/null || echo "MISSING: gh auth"

• IF git is missing → print install instructions and return status: failed (git_missing). Stop. Do not commit or push.
• IF gh is missing → print install instructions (https://cli.github.com/) and return status: failed (gh_missing). Stop. Do not commit or push.
• IF gh auth status fails → print gh auth login instructions and return status: failed (gh_unauthenticated). Stop. Do not commit or push.
• Do not print token or login output that contains credentials.

Credential rule: Never print, echo, or log tokens, PATs, or gh auth output that contains credentials. Reference credentials only via environment variable names.

Fork Mode (FORK_ORG set)

By default (no FORK_ORG) this skill pushes the fix branch directly to the cloned repo's own origin and opens a same-repo branch→base PR. That requires the authenticated gh/git identity to have direct write access to every upstream repo image-repo-mapping might resolve to (e.g. openshift/cert-manager-operator, openshift/cert-manager, openshift/secrets-store-csi-driver-operator, ...). In an unattended CI/RWS runner that isn't a collaborator on all of those repos, that's the wrong default.

IF the environment variable FORK_ORG is set (e.g. a bot-owned org), push to a fork under that org instead and open a cross-repo PR — mirrors the fork/upstream model used elsewhere for automated OpenShift PRs. This section only changes where the branch is pushed and how the PR's --head is specified; Step 0 (safety gates), Step 1 (org/repo/base-branch resolution from origin), Step 2 (conflicting-PR detection), and Step 3b (commit, allowlist validation) are unchanged and still operate against REPO_DIR/ORG/REPO/BASE_BRANCH resolved from origin.

Resolve the fork repo

FORK_REPO="${FORK_ORG}/${REPO}"   # REPO = repo name parsed from origin in Step 1, e.g. "cert-manager-operator"

Ensure the fork exists and is actually a fork of this repo

Never assume a repo at ${FORK_REPO} is the right push target just because the name matches — verify its fork lineage first. Reusing an unrelated (or unexpectedly renamed/transferred) repo that happens to occupy that name would push the fix branch and open a PR from somewhere unintended.

if FORK_JSON=$(gh repo view "${FORK_REPO}" --json isFork,parent 2>/dev/null); then
  IS_FORK=$(echo "$FORK_JSON" | jq -r '.isFork')
  PARENT_FULL_NAME=$(echo "$FORK_JSON" | jq -r '.parent.fullName // empty')
else
  IS_FORK=""
  PARENT_FULL_NAME=""
fi

• IF ${FORK_REPO} exists (the gh repo view above succeeded) and (IS_FORK is not exactly true or PARENT_FULL_NAME is not exactly ${ORG}/${REPO}) → stop immediately, do not add the fork remote or push anything, and return status: failed (fork_wrong_lineage).
• IF ${FORK_REPO} exists and lineage matches → skip fork creation below, continue to Step 3a.
• IF ${FORK_REPO} does not exist → create it:

gh repo fork "${ORG}/${REPO}" --org "${FORK_ORG}" --remote=false --clone=false --default-branch-only=false
FORK_CREATE_EXIT=$?

• IF FORK_CREATE_EXIT is non-zero → stop immediately and return status: failed (fork_create_failed). Do not poll, do not add the fork remote, do not push — the create call already reported failure, so there is nothing to wait for.
• IF FORK_CREATE_EXIT is 0 → the fork was accepted; poll briefly, since GitHub creates forks asynchronously:

for i in $(seq 1 10); do
  gh repo view "${FORK_REPO}" >/dev/null 2>&1 && break
  sleep 3
done

• IF the fork still doesn't exist after polling → return status: failed (fork_create_failed). Do not fall back to pushing to origin — that would silently switch to requiring direct upstream write access, which is exactly what FORK_ORG was set to avoid.

3a (fork mode). Branch — same as default mode

Branch creation/naming is identical to the non-fork case below (BRANCH_NAME derived from CVE_ID/SOURCE_TICKET, checked out from BASE_BRANCH).

3c (fork mode). Push to the fork, not origin

git -C "${REPO_DIR}" remote add fork "https://github.com/${FORK_REPO}.git" 2>/dev/null \
  || git -C "${REPO_DIR}" remote set-url fork "https://github.com/${FORK_REPO}.git"

# Keep the fork in sync with the upstream base branch before pushing a branch built on top of it,
# so the PR diff is just this fix — not a stale-fork drift diff.
git -C "${REPO_DIR}" fetch origin "${BASE_BRANCH}"
git -C "${REPO_DIR}" push fork "refs/remotes/origin/${BASE_BRANCH}:refs/heads/${BASE_BRANCH}" --force-with-lease 2>/dev/null || true

git -C "${REPO_DIR}" push -u fork "${BRANCH_NAME}"

Never force-push ${BASE_BRANCH} on origin (the upstream repo) — the force-with-lease sync above only ever targets the fork remote's copy of that branch name, never origin.

Step 4 (fork mode). Create the PR across fork → upstream

Do not use gh pr create --head "${FORK_ORG}:${BRANCH_NAME}". gh pr create --head only supports a user-owned head repo via the owner:branch syntax — per gh pr create --help: "Using an organization as the owner is currently not supported" (tracked at cli/cli#10093). Since FORK_ORG may be a GitHub organization, use the REST API's head_repo parameter instead (via gh api), which unambiguously names the head repository regardless of whether FORK_ORG is a user or an org:

printf '%s' "${PR_BODY}" > "${WORK_CVE}/pr-body.md"

PR_URL=$(gh api \
  "repos/${ORG}/${REPO}/pulls" \
  -f head_repo="${FORK_REPO}" \
  -f head="${BRANCH_NAME}" \
  -f base="${BASE_BRANCH}" \
  -f title="${PR_TITLE}" \
  -F body=@"${WORK_CVE}/pr-body.md" \
  --jq '.html_url')

head is the bare branch name here (no owner: prefix) — disambiguation comes entirely from the separate head_repo field, so this works whether FORK_ORG/FORK_REPO is user- or org-owned. Everything else (title/body construction, stacked-PR update path) is unchanged; PR_URL is captured directly from the API response instead of gh pr create's output.

Auth note

gh auth status in Prerequisites must reflect a token with public_repo (classic PAT) or equivalent fork/push/PR scope on ${FORK_ORG} and PR-creation scope against the upstream repo — this is set up by the caller before this skill runs (not part of this skill). Never echo the token itself.

Step 0: Safety Gates

1. IF embargo_status = True → abort immediately. Do not commit, push, create a PR, or mention ticket contents.

2. IF Phase 5 did not complete successfully → return status: skipped (phase5_incomplete).

3. Confirm there are local changes to commit:

   git -C "${REPO_DIR}" status --porcelain
   git -C "${REPO_DIR}" diff --stat

   • IF working tree is clean and HEAD is already on a fix branch with the Phase 5 remediation committed (dependency bump, source, or config) → validate that branch's changes against PHASE5_FILES (see the check in Step 3b) before skipping to Step 4. A clean worktree only means nothing is uncommitted; it does not prove the existing commit(s) contain only Phase 5 paths. IF the branch diff vs ${BASE_BRANCH} contains paths outside PHASE5_FILES → always return status: failed (phase5_files_mismatch) immediately. Never gated by AUTO_APPROVE and never prompt.
   • IF working tree is clean and HEAD is still ${GIT_BRANCH} with no Phase 5 commit → return status: skipped (no_local_changes).

4. IF AUTO_APPROVE=no (and the parent hasn't already recorded a yes) → Ask:

   Phase 5 applied the fix locally. Create a GitHub PR against <GIT_BRANCH>?

   • IF no → return status: skipped (user_declined). Leave the working tree as-is.
   • IF yes → continue. Still do not commit until Step 3.

   IF AUTO_APPROVE=yes → treat as yes, skip the prompt, continue. Still do not commit until Step 3.

Step 1: Resolve GitHub Repo and Base Branch

git -C "${REPO_DIR}" remote get-url origin

Parse ORG/REPO from the origin URL (github.com/openshift/hypershift.git → openshift/hypershift). If origin is SSH (git@github.com:org/repo.git), parse the same way.

BASE_BRANCH = GIT_BRANCH from Phase 0.7 (the mapped release branch the clone is on). Do not open the PR against main unless that is actually GIT_BRANCH.

Step 2: Detect Conflicting Open PRs

Title match only. Do not inspect PR files, body, module versions, or go.mod diffs.

gh pr list --repo "${ORG}/${REPO}" --state open --base "${BASE_BRANCH}" \
  --json number,title,url,headRefName,author

A PR is a match if its title contains (case-insensitive) either this CVE_ID, or SOURCE_TICKET (when set).

IF none → continue to Step 3 with strategy new.

IF any match:

• AUTO_APPROVE=no → present the list and wait for the user:

  Open PR(s) on <ORG/REPO> base <BASE_BRANCH> already have this CVE/Jira in the title:
  
    #<N>  <title>  <url>  head=<branch>
  
  How should I proceed?
    1. stack     — check out that PR branch, commit this fix on top, push (PR updates)
    2. wait      — stop; do not open a competing PR
    3. independent — new branch from <BASE_BRANCH> (may need rebase later)

  Choice	Action
  stack	git fetch origin <headRefName> && git checkout <headRefName> && git pull. Re-apply leftover Phase 5 changes if they are not already on that branch (same method as Phase 5 — bump, patch, or config edit). Strategy = stack.
  wait	Return status: skipped (user_wait_for_pr) including the existing PR URL.
  independent	Warn that a second PR on the same base may need rebase later. If go.mod is in this diff, mention possible module-file conflicts. Strategy = new.
  No answer	Do not guess. Ask again.

• AUTO_APPROVE=yes → always wait, automatically, with no exceptions: return status: skipped (user_wait_for_pr_auto) including the existing PR URL. Never auto-choose stack (that pushes commits onto a branch nobody reviewed for this run) or independent (that opens a second, possibly duplicate/conflicting PR) unattended. Log clearly that this run stopped because of the existing PR, so a human can revisit with --auto-approve=no if a different resolution is actually wanted.

Step 3: Branch, Commit, Push

Work only inside REPO_DIR.

Vendor: Phase 5 already ran go mod vendor/make vendor (if applicable) and included any resulting paths in PHASE5_FILES before verification. Do not run vendor sync here — doing so after PHASE5_FILES was written would generate paths that never make it into the allowlist and get silently dropped from the commit. IF a dependency bump is present in PHASE5_FILES but vendor/ looks out of sync (e.g. go mod vendor reports diffs) → stop and tell the user to re-run Phase 5, rather than fixing it here.

3a. Branch

New PR (strategy = new):

git -C "${REPO_DIR}" fetch origin "${BASE_BRANCH}"
git -C "${REPO_DIR}" checkout "${BASE_BRANCH}"
git -C "${REPO_DIR}" pull --ff-only origin "${BASE_BRANCH}"

SLUG="$(echo "${CVE_ID}" | tr '[:upper:]' '[:lower:]')"
if [ -n "${SOURCE_TICKET}" ]; then
  BRANCH_NAME="fix/${SLUG}-$(echo "${SOURCE_TICKET}" | tr '[:upper:]' '[:lower:]')"
else
  BRANCH_NAME="fix/${SLUG}"
fi

git -C "${REPO_DIR}" checkout -b "${BRANCH_NAME}"

Re-apply the Phase 5 changes on this branch if checking out BASE_BRANCH discarded uncommitted work. Prefer not discarding: stash before checkout if the working tree is dirty, then stash pop onto BRANCH_NAME.

Stack (strategy = stack): already on the existing PR branch. Set BRANCH_NAME to that head ref. Do not create a new branch.