Skip to content

fix(patch-release): derive the CM version slot from the target version #757

fix(patch-release): derive the CM version slot from the target version

fix(patch-release): derive the CM version slot from the target version #757

Workflow file for this run

name: Gemini PR Review
# Thin caller of the Gemini reusable in HarperFast/ai-review-prompts.
# Runs in parallel with claude-review.yml so the two reviewers can be
# compared on the same PRs.
#
# Layer inputs and `repo-specific-checks:` MIRROR claude-review.yml in
# this repo. Output comparability between the two providers depends on
# them seeing the same review scope — keep them in sync when bumping
# the pin or editing the checks block.
#
# Opt-in by default: Gemini runs only when a HarperFast org member
# applies the `gemini-review` label, UNLESS the GEMINI_ALWAYS_ON repo
# variable is set to 'true' (then it auto-reviews trusted-author PRs,
# like claude-review). See ai-review-prompts USAGE.md "Reviewers & the
# always-on toggle".
#
# Pre-requisites:
# - HARPERFAST_AI_CLIENT_ID (the App's Client ID, like Iv23li…)
# - HARPERFAST_AI_APP_PRIVATE_KEY (.pem file contents)
# - GEMINI_API_KEY (per-repo; optional — a missing key
# cleanly skips the review with a
# workflow notice, so this is safe to
# merge before the key is set)
# - AI_REVIEW_LOG_TOKEN (optional — threads each run into a
# per-(PR, provider) issue in
# HarperFast/ai-review-log with the
# `provider:gemini` label)
on:
pull_request:
# `labeled` admits the `gemini-review` opt-in gesture. `vars.*`
# can't be read in `on:` (only in a job `if:`), so the trigger
# lists the union and the `review` job gates on GEMINI_ALWAYS_ON.
types: [opened, synchronize, reopened, labeled]
concurrency:
# Different group key from claude-review so the two providers can run
# in parallel on the same PR.
group: gemini-review-${{ github.event.pull_request.number }}
cancel-in-progress: true
jobs:
review:
# Always-on toggle — see ai-review-prompts USAGE.md "Reviewers & the
# always-on toggle". GEMINI_ALWAYS_ON=true (repo/org variable) → auto-
# review trusted-author PRs; unset → opt-in via the gemini-review
# label. The reusable's authorize job still owns WHO is admitted
# (CODEOWNERS trust set; the labeler, not the author, on `labeled`).
# Note: the `gemini-review` label name is matched there too —
# `_gemini-review.yml`'s authorize `if:`, not in this caller.
if: ${{ vars.GEMINI_ALWAYS_ON == 'true' || github.event.action == 'labeled' }}
uses: HarperFast/ai-review-prompts/.github/workflows/_gemini-review.yml@82c9484f6f2560be4a37032858311e429bccd56c # main 2026-07-21 (#73 severity-deflation + fail-closed calibration, #74 caller hygiene; on 9cf49d2 = #70 + #71)
# Caller-side permissions at the calling-job level (NOT workflow-
# level — that placement caps the reusable's per-job grants below
# what they need and breaks the workflow at startup; see
# ai-review-prompts#39/#40). Union of what the reusable's authorize
# (`contents: read`) and review (`contents: read` + `pull-requests:
# write` + `id-token: write`) jobs declare.
permissions:
contents: read
pull-requests: write
id-token: write
with:
# Same SHA as the `uses:` ref above. The reusable uses this to
# check out HarperFast/ai-review-prompts (layer files + bash
# scripts) at the same ref as the workflow logic itself. The
# duplication is unavoidable: reusable workflows can't introspect
# their own ref (`github.workflow_ref` resolves to the CALLER's
# ref in workflow_call context), and `uses: …@<ref>` is literal.
ai-review-prompts-ref: 82c9484f6f2560be4a37032858311e429bccd56c
review-layers: |
universal
harper/common
harper/v5
repo-specific-checks: |
## Repo-specific checks (Harper Pro)
Harper Pro is the proprietary layer on top of Harper core
(HarperFast/harper). Code here may add or modify Pro-only
resources/APIs and pull from Harper core internals.
- **Linter is oxlint, not eslint.** `npm run lint` runs
oxlint with `--deny-warnings`. Advice in layers that
references ESLint doesn't apply.
- **Documentation scope.** Harper docs at
https://docs.harperdb.io are authoritative for Harper
mechanics. Pro-side docs should describe Pro-only
surface, not re-explain core behavior.
- **Storage.** Same substrate as Harper core — RocksDB
primary, LMDB available via `HARPER_STORAGE_ENGINE=lmdb`.
- **Tests.** No unit-test split — `npm run test:integration`
is the test surface. Use it judiciously; integration
tests are slow.
secrets:
GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}
AI_REVIEW_LOG_TOKEN: ${{ secrets.AI_REVIEW_LOG_TOKEN }}
HARPERFAST_AI_CLIENT_ID: ${{ secrets.HARPERFAST_AI_CLIENT_ID }}
HARPERFAST_AI_APP_PRIVATE_KEY: ${{ secrets.HARPERFAST_AI_APP_PRIVATE_KEY }}