uplift-request

# Uplift Request Skill Drafts a Bugzilla uplift-approval comment for Firefox Beta, Release, and/or ESR, following the [Uplift rules](https://wiki.mozilla.org/Release_Management/Uplift_rules). > Dependencies and Bugzilla API key setup live in > [`README.md`](./README.md). Point the user there if `bmo-to-md` or > `bmo-uplift-request --check-auth` fails. This skill may run standalone (e.g. sec-moderate, non-security regressions) or after `sec-approval` has already been filed. The sanitization audit for sec-\* bugs runs exactly **once**, early in the flow, and all later steps trust that result. The Bugzilla API key config is shared with the `sec-approval` skill — if that works, this will too. Never read or print the key; use `python3 .claude/skills/uplift-request/bmo-uplift-request --check-auth` to test availability. **Arguments:** $0 Parse: - The first all-digit token with **6 or more digits** and not immediately following `--esr` is the **bug ID**. The 6-digit floor avoids collision with ESR version numbers (`--esr 140`), which are 2–3 digits. - Any token containing `/` is the **bug report path** (a folder of markdown written by `bmo-to-md`). - `--beta`, `--release`, and `--esr NN` select target channels; multiple are allowed. If none are supplied, ask after Step 1. All arguments are optional. --- ## Step 1 — Gather context ### Retrieve the bug - **sec-\* or otherwise restricted**: `mcp__moz__get_bugzilla_bug` will fail. Use the same priority order as `sec-approval`: 1. If the user supplied a bug-report path, read `summary.md` / `bug-<id>.md` from that folder. 2. Otherwise run `bmo-to-md -o /tmp/bug-<id> -a <bug_id>` (requires a Bugzilla API key — check with the `--check-auth` command above). 3. Otherwise ask the user. - **public bugs**: prefer `mcp__moz__get_bugzilla_bug`. Collect: component, keywords, severity, `sec-*` level (if any), existing `status-firefoxNN` / `tracking-firefoxNN` flags, regressor bug if known, and any prior uplift comments. ### Inspect local commits ```bash # Detect VCS jj --version 2>/dev/null && echo "jj" || echo "git" ``` **git:** ```bash git log --oneline origin/main..HEAD git log origin/main..HEAD --format=%B git diff --stat origin/main..HEAD # overview first — the full diff can # be large; read hunks selectively git diff origin/main..HEAD -- <file> # for each file of interest ``` **jj:** ```bash jj log -T builtin_log_detailed -r 'trunk()..@' jj diff --stat -r 'trunk()..@' # overview first jj diff -r 'trunk()..@' <file> # for each file of interest ``` Record: commit messages, every `Differential Revision: .../D<N>` trailer, and the full diff. ### Current release context ``` WebFetch: https://whattrainisitnow.com/calendar/ ``` Extract current Nightly, Beta, Release, and live ESR versions. Also read the local tree version if available: `cat config/milestone.txt`. --- ## Step 2 — Determine target channel(s) If the user did not pass `--beta` / `--release` / `--esr NN`, ask with a single `AskUserQuestion` (multiSelect) using concrete versions from the calendar (e.g. "Beta 149", "ESR 140", "ESR 128"). Only offer ESR versions that are currently supported. A single block may cover several channels when they share the same patch. See Step 6 for the block-grouping rule (one block per distinct patch variant, not per channel). --- ## Step 3 — Check whether patches are on the bug Goal: know which of the four scenarios below we're in, so Step 4 can audit exactly once. 1. **List attachments** (the script never prints the API key): ```bash python3 .claude/skills/uplift-request/bmo-uplift-request <bug_id> --list ``` This prints each active Phabricator and raw-patch (`text/plain`) attachment with its ID, Phabricator revision (if any), summary, and current flags. 2. **Match** each local commit against the attachments: - **Strong — Phabricator**: `Differential Revision: .../D<N>` trailer matches an attachment whose summary or (decoded) data contains `D<N>`. - **Strong — raw patch**: fetch the `text/plain` attachment content and compare the first few `diff --git` hunk headers against the local diff. Matching file paths + identical hunk headers is a strong match; identical bodies is conclusive. - **Weak**: title/summary overlap only — treat as "possible", confirm with the user before trusting. 3. **Record the scenario** (sec-\* cases only — non-sec bugs skip Step 4): - **A.** No matching attachments. Local has the patches. → User hasn't submitted. Audit local commits. - **B.** Same as A, but the user only wants the form drafted (no submission). → Audit local commits. - **C.** Attachments match local. → Audit local commits (same content). - **D.** Attachments exist but diverge from local, or there are no local commits. → Audit what we can fetch: raw-patch attachment content and/or local commits if present. For Phabricator attachments with no local match we cannot pull the diff without Phab auth — flag that to the user and ask them to confirm the attached patches were sanitized. Present the outcome as a short table before branching. --- ## Step 4 — Sanitization audit (sec-\* only, runs once) Skip this entire step for non-sec bugs. Run **Phase 1 — Compliance Audit** from the `sec-approval` skill (commit messages, inline comments, identifiers, tests, Try server, obfuscation). Do not duplicate the audit text here — follow the checks in `.claude/skills/sec-approval/SKILL.md` Phase 1 and present the same PASS/FAIL table. **Inputs, per scenario from Step 3:** | Scenario | What to audit | | -------- | ------------------------------------------------------------------------------------ | | A, B | Local commits (and diffs). | | C | Local commits (same content as the attachments). | | D | Local commits if any; raw-patch attachment content; for Phabricator-only, ask user. | **Outcome:** - **All PASS** → set an internal flag `sanitization_ok = true`. Steps 5 and 6 proceed without re-auditing. - **Any FAIL** → block. Present the specific violations with suggested fixes and ask the user to resolve them. After fixes, re-run this step. If attachments on the bug already contain unsanitized content (scenario C/D where the audit fails), remind the user they must update both local **and** re-submit the sanitized version (Step 5) before continuing. No downstream step runs the audit again. --- ## Step 5 — Submit path (only if patches aren't on the bug, or need re-submission) Triggers: - Scenario A: user asks Claude to submit. - Scenario D after a re-sanitization. Two submit paths. Prefer **5a (moz-phab uplift)** unless the user has a concrete reason to fall back to raw-patch attachments. Either path is user-visible and hard-to-reverse — always confirm before running. Scenario B (user submits themselves later) — skip this step; just tell the user which commands to run when they are ready. ### 5a — moz-phab uplift (preferred) The moz-phab uplift flow creates a new Phabricator revision per target train, and a bot automatically adds Release Managers as reviewers when the lando uplift form is completed. Wiki: <https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift#Requesting_Uplift_using_moz-phab> On path 5a the Step 7 answer file is **not** posted as a BMO comment — instead the user pastes its contents into the lando uplift form (URL printed at the end of each `moz-phab uplift` run). Skip Step 8 in that case. **Preflight (once per run):** 1. `moz-phab uplift --list-trains` confirms train names (they begin with `firefox-` and do not always match the branch name; e.g. `firefox-esr140`, `firefox-esr115`, `firefox-beta`, `firefox-release`). 2. **Check whether each target branch already has the fix.** A Nightly library uprev (libaom/libvpx/dav1d/etc.) often carries the upstream fix across merge day — e.g. once Beta rotates forward, Beta may already contain the patched file. Confirm before committing any uplift work: ```bash git fetch upstream <target-branch> # File check: does the target version still have the pre-fix marker? git show upstream/<target-branch>:path/to/file \ | grep -c '<pre-fix-token>' # History check: does the uprev bug already live on the branch? git log --oneline upstream/<target-branch> -- path/to/file | head ``` If the fix is already present, skip that channel entirely and tell the user — the corresponding `approval-mozilla-*?` flag on any pre-existing raw-patch attachment is now moot. **Per-channel flow:** for each channel that still needs the patch, 1. Ensure the worktree is on `mozilla-firefox/firefox` and the target tip is fetched (`upstream/beta`, `upstream/release`, `upstream/esrNN`). 2. Stash irrelevant working-tree modifications so only the uplift diff is present: ```bash git stash push -m "uplift-tmp" -- <paths-to-stash> ``` 3. Create a local branch off the target tip and commit the uplift patch. Cherry-pick when the same diff applies verbatim; otherwise `git apply` the prepared `.patch` file: ```bash git checkout -b bug-<bug_id>-<channel> upstream/<target-branch> git cherry-pick <uplift-commit> # OR git apply /path/to/bug<bug_id>-uplift-<channel>.patch git add <paths> && git commit -m "<sanitized subject>" ``` 4. **Sanitized commit subject for sec-\* bugs.** The subject propagates into the Phabricator revision title, bot notifications, and CI logs — keep it maximally generic. Good: `Bug <id> - Cherry-pick <library> fix`, `Bug <id> - Backport <library> patch`. Avoid words that hint at the bug class: *thread-safety, race, bounds, overflow, use-after-free, free, UAF, heap*, or specific symbol/file names (`grain_synthesis.c`, `add_film_grain_run`, etc.). Strip the commit body entirely. 5. **Default to `--no-wip` (Needs Review on creation).** Do not use moz-phab's WIP/Changes-Planned default for uplifts. Going `--no-wip` from the start is what gets the BMO `approval-mozilla-<train>?` flag set automatically, because BMO's Phab→BMO sync only runs the flag-creation block when `is_new=true` and the revision is in `needs-review` (not `changes-planned`) at the moment of attachment creation. WIP submissions miss that window and the flag has to be set manually afterwards. WIP would only be "safer" if you wanted to eyeball the Phab revision before Release Managers see it — but Release Managers aren't added as blocking reviewers until the lando form is submitted, so WIP buys nothing in practice and costs the auto-flag. 6. Run `moz-phab uplift --train <train> --no-wip <base-rev> <tip-rev>`: ```bash moz-phab uplift --train firefox-esr140 --no-wip upstream/esr140 HEAD ``` `--yes` skips interactive confirmation; `--no-rebase` is useful when the patch has already been adapted for the target branch. 7. Open the lando URL printed at the end of the run (`https://lando.moz.tools/uplift/request/?revisions=<rev-id>`) and paste the Step 7 answer file into the nine-question uplift form — completing the form is what actually requests `#release-managers` review and posts the questionnaire to the bug. Do this for each per-channel revision. 8. **After the user submits the lando form, verify the approval flag on the resulting BMO attachment.** With `--no-wip` submissions the flag should already be present. Confirm: ```bash python3 .claude/skills/uplift-request/bmo-uplift-request \ <bug_id> --list ``` For each per-channel attachment, look for `approval-mozilla-<train>?` (e.g. `approval-mozilla-esr140?` after a firefox-esr140 submission). If it's there, done. If it's missing (which can still happen — see the WIP fallback in step 9), set it manually using the script's flag-only mode: ```bash python3 .claude/skills/uplift-request/bmo-uplift-request \ <bug_id> --attachment <id> --<channel> # e.g. --beta or --esr 140 ``` No `comment_file` argument means no comment in the PUT, so the manual fix won't duplicate the lando-posted comment. Map attachment ID → channel by reading the lando-created attachments' `file_name` field, which has the form `phabricator-D<rev>-url.txt`; cross-reference each D-rev against the moz-phab output you captured at submission. 9. **WIP fallback (legacy / corner case).** If for some reason a revision was already submitted WIP and you need to flip it to Needs Review, the local commit must first carry a `Differential Revision: https://phabricator.services.mozilla.com/D<id>` trailer so moz-phab updates the existing revision instead of creating a duplicate: ```bash git commit --amend -m "$(git log -1 --format=%s) Differential Revision: https://phabricator.services.mozilla.com/D<id>" moz-phab uplift --train <train> --no-wip --no-rebase --yes \ upstream/<target-branch> HEAD # If a duplicate got created first, abandon it: moz-phab abandon D<duplicate-id> --yes ``` The flip itself does **not** retroactively trigger BMO's flag-creation block (BMO looks up the changer in the reviewer list, finds the patch author isn't a reviewer, and returns early without setting the flag). So after a flip you still need step 8's manual flag-set fallback. **Reusing one worktree for several channels.** Fine — just create a fresh `bug-<bug_id>-<channel>` branch off each target tip. Cherry-pick from the first channel's branch. Between channels, the stash and any untracked files ride along. **Sec-\* bug visibility.** `moz-phab uplift` inherits the bug's Phabricator security group — revisions created from a media-core-security (or similar) bug are "secure" and visible only to that group, matching the existing Phabricator attachments. Verify this on the first revision you create before proceeding to the rest. ### 5b — Raw patch + BMO approval flags (fallback) Use when moz-phab uplift isn't applicable — e.g. the bug predates moz-phab uplift support, or the patch only exists as a text file and the user doesn't want to turn it into a Phabricator revision. Upload via the helper script; it can set approval flags and post the Step 7 comment in the same API call. ```bash git format-patch -1 HEAD -o /tmp python3 .claude/skills/uplift-request/bmo-uplift-request \ <bug_id> --attach /tmp/0001-*.patch --dry-run # If the dry-run looks right, re-run without --dry-run. ``` The summary defaults to the patch Subject (with `[PATCH n/m]` stripped); pass `--summary` to override. When re-submitting a sanitized version after Step 4 flagged the existing attachment (scenario D), pass `--obsolete <old_attachment_id>` (repeatable) so the stale patch is marked obsolete atomically with the upload. Combine `--attach` with `--beta` / `--release` / `--esr NN` (and an optional positional comment file) to upload the patch, post the uplift form, and set approval flags in a single API call.