ci: update to install-action v2.77.6#119
Conversation
Signed-off-by: David Gardner <dagardner@nvidia.com>
…wasm-pack Signed-off-by: David Gardner <dagardner@nvidia.com>
Signed-off-by: David Gardner <dagardner@nvidia.com>
WalkthroughThis PR updates all GitHub Actions workflows to use a newer version of ChangesGitHub Actions and Build Tool Updates
🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Comment |
install-action v2.77.6install-action v2.77.6
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
justfile (1)
994-1012:⚠️ Potential issue | 🔴 CriticalWindows ARM64 wasm-pack installation will fail silently.
The PR removes Windows ARM64 workarounds and relies on
taiki-e/install-actionv2.77.6 to installwasm-pack0.14.0. However, wasm-pack does not provide pre-built binaries for Windows ARM64 (aarch64-pc-windows-msvc)—upstream only builds for x86_64-pc-windows-msvc. The action cannot install missing binaries, and the failure is masked bycontinue-on-error: ${{ startsWith(matrix.platform, 'windows') }}on line 41 ofci_wasm.yml.Either remove
windows-arm64from the test matrix or provide a fallback installation method (e.g.,cargo install wasm-pack) for that platform.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@justfile` around lines 994 - 1012, The CI currently relies on taiki-e/install-action to install wasm-pack but upstream provides no Windows ARM64 (aarch64-pc-windows-msvc) binary, so tests on windows-arm64 will silently fail; either remove windows-arm64 from the test matrix in ci_wasm.yml (so it is not included in the matrix used by the test-wasm just target) or add a platform-specific fallback in the workflow for that matrix entry that runs a cargo-based install (e.g., run `cargo install wasm-pack` or build from source) before invoking the test job, and ensure the workflow does not rely on continue-on-error to hide installation failures. Reference the test target name test-wasm and the CI matrix/platform handling in ci_wasm.yml when making the change.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@justfile`:
- Around line 994-1012: The CI currently relies on taiki-e/install-action to
install wasm-pack but upstream provides no Windows ARM64
(aarch64-pc-windows-msvc) binary, so tests on windows-arm64 will silently fail;
either remove windows-arm64 from the test matrix in ci_wasm.yml (so it is not
included in the matrix used by the test-wasm just target) or add a
platform-specific fallback in the workflow for that matrix entry that runs a
cargo-based install (e.g., run `cargo install wasm-pack` or build from source)
before invoking the test job, and ensure the workflow does not rely on
continue-on-error to hide installation failures. Reference the test target name
test-wasm and the CI matrix/platform handling in ci_wasm.yml when making the
change.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 50218d50-a83d-4f61-ade0-cce70dc9e0e0
📒 Files selected for processing (10)
.github/workflows/ci.yaml.github/workflows/ci_check.yml.github/workflows/ci_docs.yml.github/workflows/ci_go.yml.github/workflows/ci_license_diff.yml.github/workflows/ci_node.yml.github/workflows/ci_python.yml.github/workflows/ci_rust.yml.github/workflows/ci_wasm.ymljustfile
📜 Review details
🧰 Additional context used
📓 Path-based instructions (5)
.github/workflows/**/*.{yml,yaml}
📄 CodeRabbit inference engine (.agents/skills/maintain-ci/SKILL.md)
.github/workflows/**/*.{yml,yaml}: Putpermissions:on each job that needs token access in GitHub Actions workflows
Avoid workflow-level permissions unless the repository intentionally centralizes them and the inheritance tradeoff is documented
Keep third-party actions pinned to full commit SHAs and preserve the readable version comment after the SHA
Prefer action-native or ecosystem-native caching over genericactions/cachein GitHub Actions workflows
Use lockfiles or dependency manifests to drive cache invalidation in GitHub Actions workflows
Keep deploy and publish permissions isolated to the jobs that need them
Read both caller and callee when a workflow usesworkflow_callin GitHub Actions
Put release-tag validation in the earliest practical caller job when the pipeline has tag-based publish behavior
Keep release-tag policy aligned withRELEASING.md: raw SemVer tags only, no leadingv
contents: readis the default minimum for checkout-based build, test, docs, and packaging jobs
pull-requests: readis required for PR metadata lookup jobs in GitHub Actions workflows
pages: writeandid-token: writeshould be limited to Pages deployment jobs and any caller that invokes them through a reusable workflow
For reusable workflows, the caller must grant every permission the called jobs require and the callee cannot elevate beyond what the caller provides
Preferastral-sh/setup-uvcache support withcache-dependency-globanchored touv.lockfor Python dependency caching
PreferSwatinem/rust-cachewith explicitshared-keyandworkspacesinstead of ad hoc target-directory caching
Avoid caching generated outputs that can hide stale behavior unless the repo already relies on them deliberately
Ensure each job has the minimum permissions it needs during GitHub Actions CI review
Ensure reusable workflow callers grant only the scopes their callees require
Ensure every external action is pinned to a full SHA in GitHub Actions workflows
Ensure cache ...
Files:
.github/workflows/ci_rust.yml.github/workflows/ci_license_diff.yml.github/workflows/ci_docs.yml.github/workflows/ci_python.yml.github/workflows/ci_go.yml.github/workflows/ci.yaml.github/workflows/ci_node.yml.github/workflows/ci_check.yml.github/workflows/ci_wasm.yml
{.github/**/*.{yml,yaml},*.patch,scripts/**/*,*.sh,*.bat,Dockerfile*}
📄 CodeRabbit inference engine (.agents/skills/rename-surfaces/SKILL.md)
Update CI configuration, patch files, and build scripts with new functional identifiers after rename operations
Files:
.github/workflows/ci_rust.yml.github/workflows/ci_license_diff.yml.github/workflows/ci_docs.yml.github/workflows/ci_python.yml.github/workflows/ci_go.yml.github/workflows/ci.yaml.github/workflows/ci_node.yml.github/workflows/ci_check.yml.github/workflows/ci_wasm.yml
{.github/workflows/*.{yml,yaml},.gitlab-ci.yml}
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Ensure CI workflow references match local package names and installation methods
Files:
.github/workflows/ci_rust.yml.github/workflows/ci_license_diff.yml.github/workflows/ci_docs.yml.github/workflows/ci_python.yml.github/workflows/ci_go.yml.github/workflows/ci.yaml.github/workflows/ci_node.yml.github/workflows/ci_check.yml.github/workflows/ci_wasm.yml
{.github/**,.gitlab-ci.yml,.pre-commit-config.yaml,justfile,scripts/**}
⚙️ CodeRabbit configuration file
{.github/**,.gitlab-ci.yml,.pre-commit-config.yaml,justfile,scripts/**}: Review automation changes for reproducibility, pinned versions where appropriate, secret handling, and consistency with the documented validation matrix.
Pay attention to commands that need generated native artifacts, FFI libraries, or platform-specific environment variables.
Files:
.github/workflows/ci_rust.yml.github/workflows/ci_license_diff.yml.github/workflows/ci_docs.yml.github/workflows/ci_python.yml.github/workflows/ci_go.yml.github/workflows/ci.yaml.github/workflows/ci_node.yml.github/workflows/ci_check.ymljustfile.github/workflows/ci_wasm.yml
justfile
📄 CodeRabbit inference engine (.agents/skills/update-project-version/SKILL.md)
When editing helper code, keep
set_project_version,set_cargo_workspace_version, andset_node_package_versionsaligned with version-update fields; maintainset_node_package_versionas a compatibility alias andset_npm_package_versionas the reusable npm JSON helper
Files:
justfile
🧠 Learnings (1)
📚 Learning: 2026-05-03T04:23:07.497Z
Learnt from: willkill07
Repo: NVIDIA/NeMo-Flow PR: 46
File: .github/workflows/ci_rust.yml:31-64
Timestamp: 2026-05-03T04:23:07.497Z
Learning: In GitHub Actions workflow YAML, it’s valid to conditionally disable a service container by setting the service container’s `image` to an empty string (`''`) via a matrix variable (e.g., `redis_service_image: ''`). This intentionally makes the runner skip service initialization for that matrix entry rather than failing the job. When reviewing workflows, don’t flag this as an error if the workflow uses an empty `image` to disable the service on specific matrix entries (e.g., OS-specific setups); verify the `image` is sourced from the matrix variable and that the service is only expected to be available when a non-empty image is provided.
Applied to files:
.github/workflows/ci_rust.yml.github/workflows/ci_license_diff.yml.github/workflows/ci_docs.yml.github/workflows/ci_python.yml.github/workflows/ci_go.yml.github/workflows/ci_node.yml.github/workflows/ci_check.yml.github/workflows/ci_wasm.yml
🔇 Additional comments (12)
.github/workflows/ci.yaml (1)
358-358: LGTM!.github/workflows/ci_check.yml (1)
83-83: LGTM!Also applies to: 88-88
.github/workflows/ci_docs.yml (1)
80-80: LGTM!.github/workflows/ci_go.yml (1)
59-59: LGTM!.github/workflows/ci_license_diff.yml (1)
60-60: LGTM!.github/workflows/ci_node.yml (1)
86-86: LGTM!Also applies to: 175-175, 251-251
.github/workflows/ci_python.yml (1)
81-81: LGTM!Also applies to: 219-219
.github/workflows/ci_rust.yml (1)
128-128: LGTM!.github/workflows/ci_wasm.yml (3)
81-91: LGTM!
95-95: LGTM!
140-142: LGTM!justfile (1)
1002-1012: LGTM!
|
/merge |
Overview
Details
Where should the reviewer start?
Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)
Summary by CodeRabbit