feat(deploy): store git commit hash in deployment logs (EXSC-330)#2017
feat(deploy): store git commit hash in deployment logs (EXSC-330)#20170xDEnYO wants to merge 3 commits into
Conversation
Captures the local codebase's git commit hash automatically inside the deployment logger (Mongo + local JSON mirror), so every deployment record can be tied back to the exact code that was deployed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
WalkthroughThis PR adds git commit hash tracking to deployment log records. A new ChangesDeployment record git commit hash tracking
Estimated code review effort: 2 (Simple) | ~15 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
script/deploy/shared/mongo-log-utils.ts (4)
518-519: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDuplicate raw-data shape risks drift.
The
validDataassertion type insidetransformRawToDeploymentre-declares the same fields asIRawDeploymentDatarather than reusing it (e.g.Pick/Omiton the interface). This PR addsGIT_COMMIT_HASH?/gitCommitHashin both places; keeping them in sync manually for every future field is easy to get wrong. Backward-compat handling itself (optional field, default'') is correctly done. As per path instructions, "explicitly treat it as an upgrade/storage-like contract and preserve compatibility (e.g., optional fields when reading older records)" — that part is satisfied here.Also applies to: 550-561, 578-579
🤖 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 `@script/deploy/shared/mongo-log-utils.ts` around lines 518 - 519, The raw deployment shape is duplicated in transformRawToDeployment, which risks future drift between validData and IRawDeploymentData. Update the validData assertion to reuse the existing IRawDeploymentData contract via Pick/Omit (or equivalent) instead of re-declaring fields like GIT_COMMIT_HASH/gitCommitHash, while keeping the backward-compatible optional read and default-empty-string behavior intact.Source: Path instructions
85-97: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick winNo indication when the working tree is dirty.
The stated goal is linking deployment records "back to the exact code state that produced them," but
git rev-parse HEADonly reflects the last commit. If there are uncommitted local changes at deploy time (a common scenario during iterative deploys), the stored hash won't actually match the deployed bytecode, which undermines the traceability the feature is meant to provide.🔍 Optional dirty-tree indicator
export function getCurrentGitCommitHash(): string { try { - return execSync('git rev-parse HEAD', { encoding: 'utf8' }).trim() + const hash = execSync('git rev-parse HEAD', { encoding: 'utf8' }).trim() + const isDirty = execSync('git status --porcelain', { + encoding: 'utf8', + }).trim().length > 0 + return isDirty ? `${hash}-dirty` : hash } catch (error) { consola.warn(`Failed to determine git commit hash: ${error}`) return '' } }🤖 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 `@script/deploy/shared/mongo-log-utils.ts` around lines 85 - 97, The git hash captured by getCurrentGitCommitHash only reflects HEAD and misses uncommitted changes, so update the logic to detect a dirty working tree before returning the identifier. Use the existing getCurrentGitCommitHash helper to also check git status in the same flow, and when the tree is dirty append a clear dirty-tree marker to the returned value so deployment records still map to the exact code state. Keep the warning path for failures, but make sure the returned identifier from getCurrentGitCommitHash distinguishes clean vs dirty states.
1-2: 🔒 Security & Privacy | 🔵 Trivial | 💤 Low valueConsider
execFileSyncoverexecSyncfor the git call.Static analysis flags
child_processusage broadly, but the command here ('git rev-parse HEAD') is a fully static string with no interpolated input, so there's no actual injection risk. Still, usingexecFileSync('git', ['rev-parse', 'HEAD'], { encoding: 'utf8' })avoids shell parsing entirely and is the more idiomatic/hardened pattern for fixed-argument subprocess calls.Also applies to: 90-97
🤖 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 `@script/deploy/shared/mongo-log-utils.ts` around lines 1 - 2, The git hash lookup in the shared Mongo log utility should avoid shell parsing by switching from execSync to the fixed-argument subprocess form. Update the helper in mongo-log-utils.ts that runs the git rev-parse HEAD command to use execFileSync with git and its arguments, keeping the UTF-8 output handling the same. Reference the existing git lookup helper and the child_process import so the change is applied consistently.Source: Linters/SAST tools
90-97: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick winMemoize the git commit hash to avoid repeated subprocess spawns.
logBatch()already computes this once per batch (seedeployment-logger.ts:210), butlog()invokesgetCurrentGitCommitHash()on every call (deployment-logger.ts:125). SinceHEADcannot change mid-script-execution, callers that log many individual deployments in one run (e.g. per-network loops) will spawn agitsubprocess for every single call. Caching the result at module scope would eliminate this redundant I/O.⚡ Proposed memoization
+let cachedGitCommitHash: string | undefined + export function getCurrentGitCommitHash(): string { + if (cachedGitCommitHash !== undefined) return cachedGitCommitHash try { - return execSync('git rev-parse HEAD', { encoding: 'utf8' }).trim() + cachedGitCommitHash = execSync('git rev-parse HEAD', { + encoding: 'utf8', + }).trim() } catch (error) { consola.warn(`Failed to determine git commit hash: ${error}`) - return '' + cachedGitCommitHash = '' } + return cachedGitCommitHash }🤖 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 `@script/deploy/shared/mongo-log-utils.ts` around lines 90 - 97, The git commit hash lookup is spawning a subprocess on every call to getCurrentGitCommitHash(), which is repeatedly invoked by log() even though the value is stable for the script run. Memoize the result at module scope in mongo-log-utils.ts so the first successful execSync('git rev-parse HEAD') is cached and reused by subsequent calls, while preserving the existing fallback behavior in the catch path. Keep the change centered around getCurrentGitCommitHash() so callers like deployment-logger’s log() and logBatch() automatically benefit without extra changes.
🤖 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 `@script/deploy/shared/deployment-logger.test.ts`:
- Around line 50-55: `createMockDeployment` still lets callers pass
`gitCommitHash` through `overrides`, even though the helper’s return type omits
it. Update the `overrides` parameter type to also exclude `gitCommitHash`
(matching the existing `Omit` on the return type), so `createMockDeployment`
cannot be used to inject a custom hash and the helper invariant stays enforced.
---
Nitpick comments:
In `@script/deploy/shared/mongo-log-utils.ts`:
- Around line 518-519: The raw deployment shape is duplicated in
transformRawToDeployment, which risks future drift between validData and
IRawDeploymentData. Update the validData assertion to reuse the existing
IRawDeploymentData contract via Pick/Omit (or equivalent) instead of
re-declaring fields like GIT_COMMIT_HASH/gitCommitHash, while keeping the
backward-compatible optional read and default-empty-string behavior intact.
- Around line 85-97: The git hash captured by getCurrentGitCommitHash only
reflects HEAD and misses uncommitted changes, so update the logic to detect a
dirty working tree before returning the identifier. Use the existing
getCurrentGitCommitHash helper to also check git status in the same flow, and
when the tree is dirty append a clear dirty-tree marker to the returned value so
deployment records still map to the exact code state. Keep the warning path for
failures, but make sure the returned identifier from getCurrentGitCommitHash
distinguishes clean vs dirty states.
- Around line 1-2: The git hash lookup in the shared Mongo log utility should
avoid shell parsing by switching from execSync to the fixed-argument subprocess
form. Update the helper in mongo-log-utils.ts that runs the git rev-parse HEAD
command to use execFileSync with git and its arguments, keeping the UTF-8 output
handling the same. Reference the existing git lookup helper and the
child_process import so the change is applied consistently.
- Around line 90-97: The git commit hash lookup is spawning a subprocess on
every call to getCurrentGitCommitHash(), which is repeatedly invoked by log()
even though the value is stable for the script run. Memoize the result at module
scope in mongo-log-utils.ts so the first successful execSync('git rev-parse
HEAD') is cached and reused by subsequent calls, while preserving the existing
fallback behavior in the catch path. Keep the change centered around
getCurrentGitCommitHash() so callers like deployment-logger’s log() and
logBatch() automatically benefit without extra changes.
🪄 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: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 160546df-9b38-4e03-a2c1-b42c87cf3963
📒 Files selected for processing (5)
script/deploy/shared/batch-deployment-queries.test.tsscript/deploy/shared/deployment-logger.test.tsscript/deploy/shared/deployment-logger.tsscript/deploy/shared/mongo-log-utils.tsscript/deploy/update-deployment-logs.ts
…ash (script/deploy/shared/deployment-logger.test.ts:50) CodeRabbit: the overrides param still accepted Partial<IDeploymentRecord>, letting callers inject a custom gitCommitHash even though the return type omits it — narrowed overrides to the same Omit as the return type. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
An empty string on execSync failure was indistinguishable from the default used for records logged before this field existed, so a failed capture (e.g. running outside a git checkout) could silently look like expected legacy data instead of surfacing as a real gap in deployment provenance. UNKNOWN is unambiguous either way. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2 participants
Which Linear task belongs to this PR?
EXSC-330
Why did I implement it this way?
Deployment records (Mongo + local JSON mirror) had no link back to the exact codebase state that produced them, making it hard to check out and verify what was actually deployed. Rather than threading a commit-hash argument through every shell script and CLI call site, the hash is captured automatically inside the shared logging layer (
getCurrentGitCommitHash()inmongo-log-utils.ts,git rev-parse HEADunder the hood) and injected byDeploymentLogger.log()/logBatch()and theupdate-deployment-logs.ts addCLI path. This keeps every existing caller unchanged and makes it impossible for a future deploy script to forget to pass it.Backward compatibility:
gitCommitHash/GIT_COMMIT_HASHis a new required field onIDeploymentRecord, but historical JSON records (which predate this field) parse fine —RecordTransformer.transformRawToDeploymenttreatsGIT_COMMIT_HASHas optional on the raw JSON shape and defaults to''when absent.Follow-up from review:
getCurrentGitCommitHash()originally fell back to''whengit rev-parse HEADfails (e.g. running outside a git checkout), which would have been indistinguishable from the "predates this field" default above and could silently look like expected legacy data on a later audit. Changed the failure fallback to the sentinel'UNKNOWN'so a real capture failure stays visible instead of blending in.Checklist before requesting a review
/pr-ready(local CodeRabbit) on this branch and resolved (or explicitly documented) all findings — see.agents/commands/pr-ready.mdcoderabbit review --base origin/main --type committed --plain→ no findings (initial pass).PR_READY_OK=1bypass used ongh pr createonly because the pre-PR gate hook misfires when run from a git worktree (known issue, unrelated to review outcome); the review itself was clean.deployment-logger.test.ts:createMockDeployment'soverridesparam didn't excludegitCommitHash, letting a test caller inject a custom hash despite the return type omitting it). Fixed in a dedicatedpr-ready:commit, verified viatsc-files+bun test(31/31 pass). The scoped local re-run (--base-commit) hit CodeRabbit's shared org rate limit before running;PR_READY_OK=1bypass used on the follow-upgit pushfor that reason. Cloud CodeRabbit will re-review the pushed fix commit as the safety net.Checklist for reviewer (DO NOT DEPLOY and contracts BEFORE CHECKING THIS!!!)