Update publishing to use OIDC - #158
Conversation
WalkthroughThe PR updates GitHub Actions versions (checkout and setup-node to v5), removes npm-token inputs from two action definitions, consolidates separate release and prerelease workflows into a unified publish workflow, and upgrades Yarn from 3.1.1 to 4.12.0 with corresponding configuration changes. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Areas requiring extra attention:
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
Coverage reportCaution Test run failed
Test suite run failedFailed tests: 9/11. Failed suites: 3/3.Report generated by 🧪jest coverage report action from d1d2dfa |
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (7)
.yarn/plugins/@yarnpkg/plugin-interactive-tools.cjsis excluded by!**/.yarn/**.yarn/plugins/@yarnpkg/plugin-typescript.cjsis excluded by!**/.yarn/**.yarn/plugins/@yarnpkg/plugin-version.cjsis excluded by!**/.yarn/**.yarn/plugins/@yarnpkg/plugin-workspace-tools.cjsis excluded by!**/.yarn/**.yarn/releases/yarn-3.1.1.cjsis excluded by!**/.yarn/**.yarn/releases/yarn-4.12.0.cjsis excluded by!**/.yarn/**yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (13)
.github/actions/create-prerelease/action.yml(2 hunks).github/actions/create-release/action.yml(0 hunks).github/workflows/benchmark.yml(1 hunks).github/workflows/discord.yml(1 hunks).github/workflows/gh-release.yml(1 hunks).github/workflows/node-docker.yml(3 hunks).github/workflows/pr.yml(2 hunks).github/workflows/prerelease.yml(0 hunks).github/workflows/publish.yml(1 hunks).github/workflows/release.yml(0 hunks).github/workflows/sync-deps.yml(1 hunks).yarnrc.yml(2 hunks)package.json(1 hunks)
💤 Files with no reviewable changes (3)
- .github/actions/create-release/action.yml
- .github/workflows/release.yml
- .github/workflows/prerelease.yml
🧰 Additional context used
🪛 actionlint (1.7.9)
.github/workflows/publish.yml
31-31: "github.event.head_commit.message" is potentially untrusted. avoid using it directly in inline scripts. instead, pass it through an environment variable. see https://docs.github.com/en/actions/reference/security/secure-use#good-practices-for-mitigating-script-injection-attacks for more details
(expression)
🔇 Additional comments (12)
.github/workflows/benchmark.yml (2)
76-76: LGTM!Formatting cleanup (trailing whitespace removal) is benign and improves consistency.
68-68: actions/checkout@v5 is stable and recommended. The upgrade to actions/checkout@v5 is a benign change to the current stable release, which uses the Node 24 runtime and is compatible with GitHub Actions runner v2.327.1 or later. No compatibility issues with the fetch-depth: 100 parameter are known..github/workflows/pr.yml (1)
15-17: GitHub Actions versions confirmed as stable.Both
actions/checkout@v5andactions/setup-node@v5are official stable releases and appropriate for this workflow's needs (linting, building, testing with Jest). No action required..github/workflows/node-docker.yml (1)
19-19: actions/checkout@v5 is available and compatible. The upgrade is stable and maintains full backward compatibility with fetch-depth settings (default behavior unchanged, supporting values like 2, 100, and 0). Requires GitHub Actions runner v2.327.1 or newer; no breaking changes across the three jobs..github/workflows/sync-deps.yml (1)
18-20: Verify GitHub Actions runner compatibility and automatic caching behavior.Both actions/checkout@v5 and actions/setup-node@v5 are stable releases (v5.0.0). However, both require GitHub Actions Runner v2.327.1 or later due to their Node 24 runtime upgrade—ensure self-hosted runners are updated if applicable.
Additionally, actions/setup-node@v5 enables automatic package-manager-aware caching by default. Since this workflow uses yarn, dependency caching will now happen automatically; verify this aligns with your caching strategy. Note that v5.1+ includes architecture in the cache key format, which may cause cache invalidation when upgrading within the v5 series.
.github/workflows/gh-release.yml (1)
11-16: GitHub Actions versions are stable and current; custom release actions appear compatible.Both actions/checkout@v5 and actions/setup-node@v5 are published, stable releases. The custom actions (.github/actions/create-release and .github/actions/create-prerelease) use standard composite action patterns with token inputs and present no obvious compatibility issues with the upgraded action versions.
.github/workflows/discord.yml (1)
14-14: No action needed—discord-webhook-notify@v2 maintains backward compatibility with v1 and is the recommended version per the official marketplace documentation..yarnrc.yml (1)
5-6: Yarn 4.12.0 configuration verified and correct.All settings in .yarnrc.yml are properly configured for Yarn 4.x:
- nodeLinker: node-modules (line 16): Valid Yarn 4.x configuration that switches from PnP to classic node_modules layout. Confirmed file
.yarn/releases/yarn-4.12.0.cjsexists.- enableGlobalCache: false (line 10): Intentional CI configuration to disable global cache.
- compressionLevel: mixed (line 8): Valid Yarn 4.x compression setting.
- yarnPath (line 22): Correctly points to existing release file.
No issues detected. All settings align with Yarn 4.x requirements and are appropriate for monorepo configuration.
.github/workflows/publish.yml (4)
77-80: Verify release job condition for null-safe access of commit message.Line 78 accesses
github.event.head_commit.messagedirectly in the job condition without null-checking. The fallback togit login the pre-ci job ensures output, but the condition here may fail if the head_commit is null. Ensure this condition is robust for all trigger scenarios (e.g., webhook payloads that lack head_commit).
131-135: Clarify OIDC + explicit token checkout pattern in prerelease job.The prerelease job checks out with
token: ${{ secrets.REPO_TOKEN }}(line 134) to enable pushing changes back to the repo. However, the workflow declaresid-token: writepermission for OIDC. Verify that:
- REPO_TOKEN is necessary for git push (OIDC may not provide write access to contents by default), or
- OIDC is fully replacing token-based authentication and REPO_TOKEN can be removed.
This clarification helps ensure the transition to OIDC is complete and REPO_TOKEN is not a legacy holdover.
169-173: Verify EndBug/add-and-commit@v9 is compatible with OIDC credentials.The prerelease job uses the
EndBug/add-and-commit@v9action to commit and push changes. Confirm that this action respects the REPO_TOKEN secret or automatically uses the checked-out credentials (from line 134) for authentication. If the action does not support OIDC tokens, consider using native git commands with the environment token instead.
101-120: OIDC for npm is correctly configured; REPO_TOKEN is properly scoped to GitHub releases.The workflow already uses OIDC for npm publishing:
setup-node@v5withpermissions.id-token: writeautomatically configures npm registry authentication via OIDC. TheREPO_TOKENis correctly scoped only to GitHub API calls ingh-release-script.jsfor creating releases, as documented in the action input description. No changes needed.
| - working-directory: ${{ inputs.package-path }} | ||
| run: echo "Changes exist in ${{ inputs.package-path }}" && yarn version prerelease && yarn npm publish --access public --tag dev | ||
| env: | ||
| NPM_TOKEN: ${{ inputs.npm-token }} | ||
| run: echo "Changes exist in ${{ inputs.package-path }}" && yarn version prerelease && yarn npm publish --access public --tag dev |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name '.yarnrc.yml' -o -name '.yarnrc' | head -10 | xargs -I {} sh -c 'echo "=== {} ===" && cat "{}"'Repository: subquery/subql-near
Length of output: 429
🏁 Script executed:
cat -n .github/actions/create-prerelease/action.ymlRepository: subquery/subql-near
Length of output: 983
🏁 Script executed:
find . -path './.git' -prune -o -name '*.yml' -o -name '*.yaml' | grep -E '(\.github/workflows|\.github/actions)' | head -20Repository: subquery/subql-near
Length of output: 383
🏁 Script executed:
grep -r "create-prerelease" .github/workflows/ 2>/dev/null | head -20Repository: subquery/subql-near
Length of output: 302
🏁 Script executed:
cat -n .github/workflows/publish.ymlRepository: subquery/subql-near
Length of output: 6082
Configure NPM_TOKEN environment variable in the publish step.
The publish step relies on .yarnrc.yml's npmAuthToken: "${NPM_TOKEN:-}" configuration, but the action does not set the NPM_TOKEN environment variable. While the workflow has id-token: write permission for OIDC, the action itself is not configured to use it. Either pass NPM_TOKEN as a secret from the calling workflow or configure the action to exchange the OIDC token for npm authentication.
🤖 Prompt for AI Agents
In .github/actions/create-prerelease/action.yml around lines 18-19, the publish
run uses .yarnrc.yml npmAuthToken but does not provide NPM_TOKEN; update the
action to set the NPM_TOKEN environment variable before running yarn (either
accept it as an input and map it from the caller's secrets, or implement OIDC
exchange logic to retrieve an npm auth token and export it as NPM_TOKEN), then
run the existing prerelease and publish commands so yarn can read npmAuthToken
from the environment.
| run: | | ||
| COMMIT_MSG_TEMP="${{ github.event.head_commit.message }}" | ||
| if [ -n "$COMMIT_MSG_TEMP" ] | ||
| then | ||
| commit_msg="$COMMIT_MSG_TEMP" | ||
| echo "commit-message=${commit_msg}" | head -n 1 >> "$GITHUB_OUTPUT" | ||
| else | ||
| commit_message=$(git log -1 --pretty=%B | head -n 1) | ||
| echo "commit-message=$commit_message" >> "$GITHUB_OUTPUT" | ||
| fi |
There was a problem hiding this comment.
Fix script injection vulnerability by passing context through environment variable.
Line 31 directly interpolates ${{ github.event.head_commit.message }} into a bash command, which is vulnerable to script injection if the commit message contains shell metacharacters.
Apply this diff to safely pass the context value through an environment variable:
- id: get_commit_message
+ env:
+ COMMIT_MSG_TEMP: ${{ github.event.head_commit.message }}
run: |
- COMMIT_MSG_TEMP="${{ github.event.head_commit.message }}"
if [ -n "$COMMIT_MSG_TEMP" ]
then
commit_msg="$COMMIT_MSG_TEMP"
echo "commit-message=${commit_msg}" | head -n 1 >> "$GITHUB_OUTPUT"
else
commit_message=$(git log -1 --pretty=%B | head -n 1)
echo "commit-message=$commit_message" >> "$GITHUB_OUTPUT"
fi📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| run: | | |
| COMMIT_MSG_TEMP="${{ github.event.head_commit.message }}" | |
| if [ -n "$COMMIT_MSG_TEMP" ] | |
| then | |
| commit_msg="$COMMIT_MSG_TEMP" | |
| echo "commit-message=${commit_msg}" | head -n 1 >> "$GITHUB_OUTPUT" | |
| else | |
| commit_message=$(git log -1 --pretty=%B | head -n 1) | |
| echo "commit-message=$commit_message" >> "$GITHUB_OUTPUT" | |
| fi | |
| - id: get_commit_message | |
| env: | |
| COMMIT_MSG_TEMP: ${{ github.event.head_commit.message }} | |
| run: | | |
| if [ -n "$COMMIT_MSG_TEMP" ] | |
| then | |
| commit_msg="$COMMIT_MSG_TEMP" | |
| echo "commit-message=${commit_msg}" | head -n 1 >> "$GITHUB_OUTPUT" | |
| else | |
| commit_message=$(git log -1 --pretty=%B | head -n 1) | |
| echo "commit-message=$commit_message" >> "$GITHUB_OUTPUT" | |
| fi |
🧰 Tools
🪛 actionlint (1.7.9)
31-31: "github.event.head_commit.message" is potentially untrusted. avoid using it directly in inline scripts. instead, pass it through an environment variable. see https://docs.github.com/en/actions/reference/security/secure-use#good-practices-for-mitigating-script-injection-attacks for more details
(expression)
🤖 Prompt for AI Agents
.github/workflows/publish.yml around lines 31 to 40: the workflow currently
interpolates ${{ github.event.head_commit.message }} directly into a shell
script which can allow script injection; instead add an environment variable in
the step (e.g., COMMIT_MSG_RAW: "${{ github.event.head_commit.message }}") and
change the script to read from that env var (COMMIT_MSG_TEMP="$COMMIT_MSG_RAW")
so no GitHub expression is expanded inside the shell; ensure you still test for
non-empty safely (use [ -n "$COMMIT_MSG_TEMP" ]) and keep all variable values
quoted when echoing to GITHUB_OUTPUT to preserve content and prevent
word-splitting or unintended execution.
| ] | ||
| }, | ||
| "packageManager": "yarn@3.1.1" | ||
| "packageManager": "yarn@4.12.0" |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Yarn 4.12.0 release stable breaking changes from Yarn 3.x to 4.x
💡 Result:
Short summary — what changed when upgrading from Yarn 3.x → Yarn 4.x (and note about 4.12.0)
Key breaking / behavior changes to watch for:
- Node requirement: Yarn 4 requires Node.js 18+ (3.x supported older Node versions). [1][2]
- Installation / versioning: new projects and tooling favor Corepack / packageManager over yarnPath;
yarn init/yarn set versionbehavior changed. If you must run on older Node, avoidyarn set versionor pin a 3.x yarnPath. [1][2][4] - Zero‑Install / cache defaults: new projects created with
yarn initno longer enable Zero‑Install by default;enableGlobalCachedefaults flipped (Zero‑Install projects may have.yarnrc.ymlupdated on first install). [1][2] - Official plugins: many official plugins (TypeScript, interactive tools, etc.) are bundled/enabled by default. [1]
- CLI changes: small command syntax changes (notably
yarn workspaces foreachsyntax). Also some flags/option renames and hardened-mode additions that tighten lockfile/resolve checks. [1][2] - Config files: same modern config file style (
.yarnrc.yml) and some config keys/defaults changed — review your.yarnrc.ymlafter migration. [2][6] - Migration friction: the maintainers attempted to avoid surprising breaking changes and many migrations are automatic, but some CI/installation flows (especially on older Node) require manual adjustments. [1][7]
About 4.12.0 specifically:
- v4.12.0 (released Nov 23, 2025) is a patch release with bug fixes (git clone arg fix, npm web login support, JSON schema fix) — it does not introduce new 4.x breaking changes beyond the 4.0 migration items above. [3]
If you want, I can:
- produce a checklist of exact changes to apply to a repo (package.json, .yarnrc.yml, CI), or
- scan your repo for likely incompatible settings and give concrete edits.
Sources:
[1] Yarn blog — Release: Yarn 4.0 (breaking changes & migration notes).
[2] Yarn changelog (4.0 / related entries).
[3] GitHub — yarnpkg/berry release v4.12.0.
[4] GitHub issue: yarn set version on Node <18 (migration/compat note).
[6] Yarn migration guide / step-by-step.
[7] GitHub discussions about 4.0 migration clarity.
Verify Yarn 4.12.0 is stable and that lock file is regenerated.
This is a major version bump from Yarn 3.1.1 to 4.12.0 with several breaking changes. Ensure the yarn.lock file has been regenerated with the new version, confirm Node.js 18+ compatibility (Yarn 4 requires Node 18+), review any changes to .yarnrc.yml configuration, and validate that all test workflows pass with the upgraded package manager.
🤖 Prompt for AI Agents
In package.json around line 56, the packageManager was changed to "yarn@4.12.0";
confirm Yarn 4.12.0 is intentionally chosen, ensure the repo is using Node.js
18+ (update engine fields or CI runners if needed), regenerate yarn.lock with
Yarn v4.12.0 (delete existing lock, run yarn install with that Yarn binary) and
commit the updated yarn.lock, review and update .yarnrc.yml for any breaking
config changes introduced by Yarn 4, and run the full test/CI workflows locally
or in CI to validate no regressions.
Summary by CodeRabbit
Release Notes
✏️ Tip: You can customize this high-level summary in your review settings.