Fixes base SHA detection in nightly workflow

[logbie]

Updates the nightly workflow to use git rev-parse for resolving the base commit SHA from the latest release tag.

This approach is more reliable than using gh release view, as it directly resolves the tag to its underlying commit hash, preventing potential issues if a release was tagged against a branch instead of a specific commit.

Summary by CodeRabbit

• Chores
  • Updated internal build workflow configuration to improve nightly build commit resolution
  • Expanded system permissions for build, version checking, and release management tools
  • Added dependency tree documentation for better dependency tracking

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[claude]

Claude Code is working…

I'll analyze this and get back to you.

View job run

[coderabbitai]

Walkthrough

Configuration and CI/CD updates expand permitted shell commands and WebSearch access in Claude settings, modify the GitHub Actions nightly workflow to resolve commit SHAs directly via git rev-parse instead of gh release view, and add a dependency tree documentation file for num-bigint-dig v0.8.4.

Changes

Cohort / File(s)	Change Summary
Configuration & Permissions \.claude/settings\.local\.json	Expanded permissions.allow list with seven new entries: Bash commands for cargo tree, cargo report, cargo --version, rustc, gh release view, git rev-parse, and WebSearch
CI/CD Workflow \.github/workflows/nightly\.yml	Modified BASE_SHA resolution for latest nightly tag; replaced gh release view method with direct git rev-parse of tag to obtain commit SHA
Documentation dependency_tree_before\.txt	Added new dependency tree file documenting num-bigint-dig v0.8.4 and its transitive dependencies (core crates: byteorder, lazy_static, libm, num-integer, num-iter, num-traits, rand, smallvec, zeroize)

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Verify that git rev-parse <tag> reliably resolves the same commit SHA as the previous gh release view method in the nightly workflow
• Confirm all new Bash command permissions and WebSearch entry are intentional and secure

Poem

🐰 Permissions flow and workflows dance,
Git rev-parse takes a cleaner stance,
Dependencies mapped with care,
New commands granted everywhere—
Configuration blooms so bright! ✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: replacing the base SHA detection method in the nightly workflow from gh release view to git rev-parse.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fileio

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e7e7ef7 and ea1c2e9.

⛔ Files ignored due to path filters (1)

• Cargo.lock is excluded by !**/*.lock

📒 Files selected for processing (3)

• .claude/settings.local.json (1 hunks)
• .github/workflows/nightly.yml (1 hunks)
• dependency_tree_before.txt (1 hunks)

🧰 Additional context used

🧠 Learnings (1)

📚 Learning: 2025-08-12T09:39:16.504Z

Learnt from: logbie
Repo: WebFirstLanguage/wfl PR: 148
File: .claude/settings.local.json:41-44
Timestamp: 2025-08-12T09:39:16.504Z
Learning: The .claude/settings.local.json file is specifically formatted for Claude AI assistant usage and should not be reformatted to standard bash command syntax. The existing formatting is intentional and optimized for Claude's permission system.

Applied to files:

• .claude/settings.local.json

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)

• GitHub Check: Build, Test, Clippy
• GitHub Check: Integration Tests (ubuntu-latest)
• GitHub Check: Integration Tests (windows-latest)
• GitHub Check: claude-review
• GitHub Check: config-lint

🔇 Additional comments (3)

.github/workflows/nightly.yml (1)

64-65: Verify error handling for git rev-parse failure.

The git rev-parse command at line 65 has no error handling. If the tag reference is invalid or the command fails, BASE_SHA will be empty but the script continues without raising an error, potentially leading to unexpected behavior downstream.

Consider adding a check:

if ! BASE_SHA=$(git rev-parse "$LATEST_TAG^{}"); then
  echo "::error::Failed to resolve tag $LATEST_TAG to a commit SHA"
  exit 1
fi

Alternatively, if you intend to allow graceful degradation (empty BASE_SHA is valid), please add a comment explaining this design decision.

.claude/settings.local.json (1)

23-30: Verify all new permissions are necessary for this PR.

Most of the new permissions appear to be unrelated to the stated PR objective (using git rev-parse for BASE_SHA resolution). While line 30's "Bash(git rev-parse:*)" directly enables the nightly workflow change, the others (cargo tree, cargo report, cargo --version, rustc, gh release view, and WebSearch) lack clear connections to this PR.

Additionally, line 29 includes "Bash(gh release view:*)", but the nightly workflow uses gh release list (line 59), not gh release view. This suggests either:

1. These permissions are for unrelated work being bundled into this PR
2. There are planned changes not yet reflected in the provided code
3. These are stale/unnecessary additions

Clarify which permissions are strictly necessary for this PR and consider splitting unrelated permission expansions into a separate PR for easier review and audit trails.

dependency_tree_before.txt (1)

1-41: Clarify purpose and version control intent for dependency_tree_before.txt.

The filename dependency_tree_before.txt suggests this is a snapshot or comparison artifact. Context is missing:

• Is this file meant to be version-controlled as documentation?
• Is there a corresponding dependency_tree_after.txt for comparison?
• Was this generated by the new cargo tree permission (line 24 in settings.local.json)?
• Should this be added to .gitignore if it's build output?

If this is intended as a reference commit for auditing dependency changes, please document the purpose (e.g., in a PR comment or README). If it's incidental build output, consider excluding it from the commit.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}