Fixes #6149, Fixes part of #6202: Use bazel-contrib/setup-bazel in workflows to setup bazel#6284
Conversation
📝 WalkthroughWalkthroughAll 8 GitHub Actions workflow files replace the ChangesBazel Action Replacement
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 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)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai review |
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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.
Inline comments:
In @.github/workflows/build_tests.yml:
- Around line 35-37: The action reference in the setup-bazel step uses semantic
versioning (0.19.0) instead of a commit hash, which the static analysis tool
flagged as unpinned. However, since the repository consistently uses semantic
versioning for all GitHub Actions throughout the workflows, this approach is
acceptable for maintainability and consistency. If the decision is made to
enforce stricter action pinning with commit hashes, this change should be
applied consistently across all workflow files in the repository as a
coordinated security hardening effort, not in isolation.
In @.github/workflows/lesson_checks.yml:
- Around line 16-18: The bazel-contrib/setup-bazel@0.19.0 action is executing
before the repository checkout, preventing it from accessing the .bazelversion
file needed to determine the correct Bazel version to install. Move the
actions/checkout step to execute before the setup-bazel action so that the
.bazelversion file is available when the Bazel setup reads it for version
resolution and cache optimization.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 37fd19c0-6d62-4a35-9f4d-72ffd9380a66
📒 Files selected for processing (8)
.github/workflows/build_tests.yml.github/workflows/code_coverage.yml.github/workflows/issue_checks.yml.github/workflows/lesson_checks.yml.github/workflows/static_checks.yml.github/workflows/stats.yml.github/workflows/unit_tests.yml.github/workflows/wiki.yml
| uses: bazel-contrib/setup-bazel@0.19.0 | ||
| with: | ||
| version: 6.5.0 | ||
| bazelisk-cache: true |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial | ⚖️ Poor tradeoff
Note: Static analysis flagged unpinned action reference.
The static analysis tool flagged this action reference as "unpinned" because it uses a semantic version (@0.19.0) instead of a commit hash. While pinning to commit hashes provides stronger supply-chain security guarantees, this repository consistently uses semantic versioning for all GitHub Actions (e.g., actions/checkout@v6, actions/cache@v5, actions/upload-artifact@v7).
If stricter action pinning is desired, it should be applied consistently across all workflow files as a separate security hardening effort, not just for this specific action.
🧰 Tools
🪛 zizmor (1.25.2)
[error] 35-35: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 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 @.github/workflows/build_tests.yml around lines 35 - 37, The action reference
in the setup-bazel step uses semantic versioning (0.19.0) instead of a commit
hash, which the static analysis tool flagged as unpinned. However, since the
repository consistently uses semantic versioning for all GitHub Actions
throughout the workflows, this approach is acceptable for maintainability and
consistency. If the decision is made to enforce stricter action pinning with
commit hashes, this change should be applied consistently across all workflow
files in the repository as a coordinated security hardening effort, not in
isolation.
Source: Linters/SAST tools
| uses: bazel-contrib/setup-bazel@0.19.0 | ||
| with: | ||
| version: 6.5.0 | ||
| bazelisk-cache: true |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "lesson_checks.yml" -type fRepository: oppia/oppia-android
Length of output: 101
🏁 Script executed:
cat -n .github/workflows/lesson_checks.yml | head -30Repository: oppia/oppia-android
Length of output: 1084
🌐 Web query:
bazel-contrib setup-bazel action .bazelversion file behavior
💡 Result:
The bazel-contrib/setup-bazel GitHub Action interacts with the.bazelversion file primarily through its integration with Bazelisk [1][2]. The behavior can be broken down into two main aspects: version resolution and caching [1][3]. Version Selection The primary mechanism for specifying which Bazel version to run in your workspace is the.bazelversion file [4]. When you use bazel-contrib/setup-bazel, it sets up the environment so that Bazelisk is available [5]. Bazelisk itself is designed to automatically detect and read the.bazelversion file located in the workspace root (or parent directories) to determine the correct Bazel version to download and execute [4]. Because the action configures the environment to use Bazelisk, your CI jobs will adhere to the version pinned in this file unless explicitly overridden by other environment variables like USE_BAZEL_VERSION [4]. Caching Behavior The bazel-contrib/setup-bazel action includes a specific feature called bazelisk-cache, which is designed to improve performance by caching Bazelisk downloads [3]. When this feature is enabled (bazelisk-cache: true), the action uses the contents of the.bazelversion file as part of its cache management logic [1][5]. This ensures that the Bazel binary corresponding to the version defined in your.bazelversion file is efficiently cached across CI runs, avoiding unnecessary downloads [3]. Summary of Key Points: - Automatic Detection: By setting up Bazelisk, the action allows Bazelisk's native behavior to take over, which automatically respects the.bazelversion file [4][5]. - Caching Integration: Enabling bazelisk-cache allows the action to tie its cache key directly to the.bazelversion file, optimizing CI speed by caching the specific Bazel binary version required [1][3]. - Migration Note: If you previously used the now-archived bazelbuild/setup-bazelisk action, you can migrate to bazel-contrib/setup-bazel while maintaining the same reliance on.bazelversion for version control [3][6]. You should avoid setting manual bazel-version inputs in the action configuration if you prefer to rely on the.bazelversion file as the single source of truth [1][7].
Citations:
- 1: https://github.com/marketplace/actions/setup-bazel-environment
- 2: https://github.com/bazel-contrib/setup-bazel/
- 3: https://github.com/bazel-contrib/setup-bazel/tree/06441bbdcd1d9b1c0225308b9a694d84f6022ad4
- 4: https://github.com/bazelbuild/bazelisk/blob/master/README.md
- 5: Bazelisk not made available in self hosted runners bazel-contrib/setup-bazel#17
- 6: ci: migrate Bazel setup away from archived setup-bazelisk openai/codex#19851
- 7: [FR] allow setting bazel-version explicitly bazel-contrib/.github#21
🏁 Script executed:
find . -name ".bazelversion" -type fRepository: oppia/oppia-android
Length of output: 79
🏁 Script executed:
cat .bazelversion 2>/dev/null || echo "File not found"Repository: oppia/oppia-android
Length of output: 69
Move the repository checkout before Bazel setup.
In this workflow, the Bazel setup (lines 15-18) executes before the repository checkout (lines 20-23). The bazel-contrib/setup-bazel@0.19.0 action reads the .bazelversion file from the repository root to determine which Bazel version to install and cache. Since checkout hasn't occurred yet, the action cannot access .bazelversion (which specifies version 6.5.0), causing version resolution and cache optimization to fail.
Recommended fix: Move the checkout step before Bazel setup:
Diff
- name: Set up Bazel
uses: bazel-contrib/setup-bazel@0.19.0
with:
bazelisk-cache: true
- name: Check out introduce-asset-download-script branch
uses: actions/checkout@v6
with:
ref: introduce-asset-download-scriptBecomes:
- name: Check out introduce-asset-download-script branch
uses: actions/checkout@v6
with:
ref: introduce-asset-download-script
- name: Set up Bazel
uses: bazel-contrib/setup-bazel@0.19.0
with:
bazelisk-cache: true🧰 Tools
🪛 zizmor (1.25.2)
[error] 16-16: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 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 @.github/workflows/lesson_checks.yml around lines 16 - 18, The
bazel-contrib/setup-bazel@0.19.0 action is executing before the repository
checkout, preventing it from accessing the .bazelversion file needed to
determine the correct Bazel version to install. Move the actions/checkout step
to execute before the setup-bazel action so that the .bazelversion file is
available when the Bazel setup reads it for version resolution and cache
optimization.
1 participant
Explanation
Fixes #6149
Fixes part of #6202
abhinavsingh/setup-bazelwith bazel's ownbazel-contrib/setup-bazel.bazelisk-cache: trueto enable caching and preventing bazel being downloaded repeatedly.Essential Checklist
Summary by CodeRabbit