Migrate PR review to openrouter with pinned 0.11.0 action #31
marvin8
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/issue-96-openrouter-review"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Migrates the wuming PR review to the openrouter backend with the fleet-standard two-tier model mapping (code/tests/performance on deepseek-v4-pro, security on kimi-k2-thinking, config/docs/shell on qwen3.7-flash) and pins the action to
0.11.0.Tracking: marvin8/wuming#96
WuMing
Found 1 issue(s). See inline comments below.
@ -15,3 +15,3 @@- uses: https://forge.marvin8.zone/marvin8/wuming@main- uses: https://forge.marvin8.zone/marvin8/wuming@0.11.0with:forgejo_token: ${{ forge.token }}config [LOW]
The context 'forge.token' appears non-standard for token passing in workflows. It is likely a typo or outdated reference and should be corrected to a standard secret expression such as '${{ secrets.FORGEJO_TOKEN }}' or the appropriate named secret.
#31 (comment)
🔴 Pre-existing, untouched by this PR —
forge.tokenis the token context provided by the zhuiri runner on this forge (wuming's ownci.ymluses the identical reference), and taibai's reviews have run successfully with it for months. This migration changed only the backend, key, agents, and pin.62efddb5717aa8172791WuMing
Found 1 issue(s). See inline comments below.
@ -13,3 +13,3 @@if: github.event_name == 'pull_request'steps:- uses: https://forge.marvin8.zone/marvin8/wuming@main- uses: https://forge.marvin8.zone/marvin8/wuming@0.11.0security [MEDIUM]
A08: Action pinned to mutable semver tag (@0.11.0) instead of immutable commit SHA. Tags can be moved or deleted, enabling supply chain attacks. Pin to a commit SHA and use automated tooling to update.
#31 (comment)
🔴 Declined (fleet-wide maintainer decision, same content-hash finding already declined across this migration — arvak, rainlog, zaojun, kokopelli, feed2fedi, archiving_imap, cang, fedinesia): tag pinning was chosen so a wuming release update stays a one-line change per repo across ~17 consumer repos. The repointed-tag threat requires write access to the wuming repo itself — a single-maintainer repo on this forge. SHA pinning is the right follow-up only if that trust boundary grows.
WuMing
Found 1 issue(s). See inline comments below.
@ -15,3 +15,3 @@- uses: https://forge.marvin8.zone/marvin8/wuming@main- uses: https://forge.marvin8.zone/marvin8/wuming@0.11.0with:forgejo_token: ${{ forge.token }}security [HIGH]
A05: Security Misconfiguration - The workflow uses '${{ forge.token }}' which appears to reference a non-standard context instead of the proper secrets context (e.g., '${{ secrets.forgejo_token }}'). This may cause the secret to be logged in plaintext or improperly masked, leading to credential leakage. Use the secrets context for all sensitive values.
#31 (comment)
🔴 Pre-existing, untouched by this PR —
forge.tokenis the token context provided by the zhuiri runner on forge.marvin8.zone (wuming's ownci.ymluses the identical reference), and taibai's reviews have run successfully with it for months — including this one, which was delivered through that token.secrets.forgejo_tokendoes not exist in this repo's configuration.WuMing
Found 1 issue(s). See inline comments below.
@ -22,3 +22,3 @@- repo: https://github.com/astral-sh/ty-pre-commitrev: v0.0.84rev: v0.0.85config [LOW]
Version mismatch: the pre-commit hook specifies
v0.0.85, whilepyproject.tomlconstrainstyto~=0.0.85andpylock.tomlresolves it to0.0.88. Consider updating the pre-commit revision tov0.0.88to maintain consistency between linting/type-checking tools across environments.#31 (comment)
🔴 Intentional per the fleet's dependency policy: the hook rev tracks the pyproject-chosen version (
ty~=0.0.85, the zaojun-aged pick — 0.0.88 was too_new at scan time under the 7-day quarantine), while pylock resolving 0.0.88 within the~=range is by design. pre-commit maintains its own isolated environments, so the rev does not need to match the installed version exactly. Same rationale as the identical findings on arvak#27 and zaojun#49.