fix: use SERVICE_VERSION env var for ccip-server version logging#7674
fix: use SERVICE_VERSION env var for ccip-server version logging#7674paulbalaji merged 1 commit intomainfrom
Conversation
Use CI-generated Docker tag (SHA + date) as SERVICE_VERSION instead of package.json version, since multiple Docker images can be built from the same npm package version. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
🐳 Monorepo Docker Image Built SuccessfullyImage Tags: |
🔍 CCIP Server Docker Image Built SuccessfullyImage Tags: |
📝 WalkthroughWalkthroughVersion management gets a makeover. SERVICE_VERSION build argument introduced to Docker workflow and Dockerfile with default 'dev', propagated to runtime environment. Server logger now reads from SERVICE_VERSION environment variable instead of importing package.json, decoupling build versioning from package metadata. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✨ 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[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
typescript/ccip-server/Dockerfile (1)
11-11: Builder stage ARG appears unused.The
SERVICE_VERSIONargument in the builder stage isn't referenced anywhere before the runner stage. Since multi-stage builds don't automatically propagate ARGs, this declaration has no effect. You only need the ARG in the runner stage (line 97) where it's actually used.🔎 Proposed cleanup
ARG FOUNDRY_VERSION -ARG SERVICE_VERSION=dev ARG TARGETARCH
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.github/workflows/ccip-server-docker.ymltypescript/ccip-server/Dockerfiletypescript/ccip-server/src/server.ts
🧰 Additional context used
📓 Path-based instructions (1)
typescript/**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
typescript/**/*.{ts,tsx}: UseChainMapfor per-chain configurations in TypeScript
Import types from@hyperlane-xyz/sdkwhen using TypeScript SDK types
Files:
typescript/ccip-server/src/server.ts
🧠 Learnings (1)
📚 Learning: 2025-12-22T16:50:19.890Z
Learnt from: paulbalaji
Repo: hyperlane-xyz/hyperlane-monorepo PR: 7565
File: typescript/ccip-server/Dockerfile:10-11
Timestamp: 2025-12-22T16:50:19.890Z
Learning: Standardize Foundry installation in Dockerfiles by using the official curl -L https://foundry.paradigm.xyz | bash followed by foundryup. This pattern is already used across multiple Dockerfiles in the repo and should be retained for consistency and reliability wherever Foundry is installed.
Applied to files:
typescript/ccip-server/Dockerfile
⏰ 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). (63)
- GitHub Check: cli-evm-e2e-matrix (warp-extend-basic)
- GitHub Check: cli-evm-e2e-matrix (core-deploy)
- GitHub Check: cli-evm-e2e-matrix (warp-apply-ism-updates)
- GitHub Check: cli-evm-e2e-matrix (warp-apply-rebalancing-config)
- GitHub Check: cli-evm-e2e-matrix (warp-check-2)
- GitHub Check: cli-evm-e2e-matrix (core-check)
- GitHub Check: cli-evm-e2e-matrix (warp-rebalancer)
- GitHub Check: cli-evm-e2e-matrix (warp-check-5)
- GitHub Check: cli-evm-e2e-matrix (core-apply)
- GitHub Check: cli-evm-e2e-matrix (warp-send)
- GitHub Check: cli-evm-e2e-matrix (warp-check-3)
- GitHub Check: cli-evm-e2e-matrix (warp-bridge-2)
- GitHub Check: cli-evm-e2e-matrix (core-read)
- GitHub Check: cli-evm-e2e-matrix (status)
- GitHub Check: cli-evm-e2e-matrix (warp-read)
- GitHub Check: cli-evm-e2e-matrix (warp-check-1)
- GitHub Check: cli-evm-e2e-matrix (warp-deploy-1)
- GitHub Check: cli-evm-e2e-matrix (warp-extend-recovery)
- GitHub Check: cli-evm-e2e-matrix (warp-deploy-2)
- GitHub Check: cli-evm-e2e-matrix (warp-bridge-1)
- GitHub Check: cli-evm-e2e-matrix (warp-apply-ownership-updates)
- GitHub Check: cli-evm-e2e-matrix (core-init)
- GitHub Check: cli-evm-e2e-matrix (warp-extend-config)
- GitHub Check: cli-evm-e2e-matrix (warp-check-4)
- GitHub Check: cli-evm-e2e-matrix (relay)
- GitHub Check: cli-evm-e2e-matrix (warp-init)
- GitHub Check: cli-evm-e2e-matrix (warp-apply-hook-updates)
- GitHub Check: cli-evm-e2e-matrix (warp-apply-submitters)
- GitHub Check: cli-evm-e2e-matrix (warp-apply-simple-updates)
- GitHub Check: env-test-matrix (testnet4, sepolia, core)
- GitHub Check: env-test-matrix (mainnet3, optimism, core)
- GitHub Check: env-test-matrix (mainnet3, ethereum, igp)
- GitHub Check: env-test-matrix (mainnet3, optimism, igp)
- GitHub Check: env-test-matrix (mainnet3, arbitrum, core)
- GitHub Check: cli-cosmos-e2e-matrix (warp-deploy)
- GitHub Check: env-test-matrix (mainnet3, arbitrum, igp)
- GitHub Check: cli-cosmos-e2e-matrix (warp-read)
- GitHub Check: env-test-matrix (mainnet3, ethereum, core)
- GitHub Check: cli-radix-e2e-matrix (core-apply)
- GitHub Check: cli-radix-e2e-matrix (warp-deploy)
- GitHub Check: cli-cosmos-e2e-matrix (core-read)
- GitHub Check: cli-cosmos-e2e-matrix (core-deploy)
- GitHub Check: cli-radix-e2e-matrix (core-deploy)
- GitHub Check: cli-radix-e2e-matrix (warp-apply-ownership-updates)
- GitHub Check: cli-cosmos-e2e-matrix (core-apply)
- GitHub Check: cli-cosmos-e2e-matrix (core-check)
- GitHub Check: cli-radix-e2e-matrix (warp-apply-route-extension)
- GitHub Check: cli-install-test-run
- GitHub Check: cli-cross-chain-e2e-matrix (warp-deploy)
- GitHub Check: aleo-sdk-e2e-run
- GitHub Check: cli-cross-chain-e2e-matrix (warp-apply)
- GitHub Check: cosmos-sdk-e2e-run
- GitHub Check: pnpm-test-run
- GitHub Check: infra-test
- GitHub Check: build-and-push-to-gcr
- GitHub Check: build-and-push-to-gcr
- GitHub Check: Greptile Review
- GitHub Check: lint-rs
- GitHub Check: lander-coverage
- GitHub Check: test-rs
- GitHub Check: e2e-matrix (evm)
- GitHub Check: agent-configs (testnet4)
- GitHub Check: agent-configs (mainnet3)
🔇 Additional comments (3)
typescript/ccip-server/Dockerfile (1)
97-101: Proper build-arg to runtime ENV propagation.The pattern correctly captures the build-time
SERVICE_VERSIONand makes it available at runtime. The 'dev' default ensures the container works even without the build arg, which is handy for local development.typescript/ccip-server/src/server.ts (1)
26-31: Clean environment-based version handling.Reading
SERVICE_VERSIONfrom the environment with a sensible 'dev' fallback makes this work smoothly in both production and local development. The version now accurately reflects the actual deployed build rather than the package metadata..github/workflows/ccip-server-docker.yml (1)
113-113: SERVICE_VERSION build-arg is solid, just make sure the pattern's consistent.The SHA-timestamp format creates unique, sortable version identifiers that properly distinguish builds from the same commit. This follows the same pattern already used in rust-docker and monorepo-docker workflows, so you're in good company.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #7674 +/- ##
=======================================
Coverage 77.02% 77.02%
=======================================
Files 117 117
Lines 2651 2651
Branches 244 244
=======================================
Hits 2042 2042
Misses 593 593
Partials 16 16
🚀 New features to boost your workflow:
|
2 participants
Summary
Test plan
🤖 Generated with Claude Code
Greptile Summary
Switched ccip-server version logging from
package.jsonversion toSERVICE_VERSIONenvironment variable, which gets set during Docker builds using a unique SHA+date identifier.SERVICE_VERSIONbuild arg with format{7-char-sha}-{timestamp}(e.g.,b9c592a-20250129-143022)SERVICE_VERSIONas ARG (defaults todev) and exposes it as ENV variableprocess.env.SERVICE_VERSIONinstead of importing frompackage.jsonpackage.jsonimport fromserver.tsThis matches the pattern the team applied to other services and ensures each Docker image has a unique version identifier even when multiple images are built from the same npm package version.
Confidence Score: 5/5
Important Files Changed
SERVICE_VERSIONbuild arg using SHA+date tag for Docker versioningSERVICE_VERSIONARG and ENV to pass build-time version through to runtimepackage.jsonversion withSERVICE_VERSIONenv var for loggingSequence Diagram
sequenceDiagram participant GHA as GitHub Actions participant Docker as Docker Build participant Container as Running Container participant Logger as Service Logger GHA->>GHA: Generate TAG_SHA (first 7 chars of commit) GHA->>GHA: Generate TAG_DATE (timestamp) GHA->>Docker: Build with SERVICE_VERSION arg<br/>(SHA-DATE format) Docker->>Docker: Set ARG SERVICE_VERSION=dev (default) Docker->>Docker: Build stage: install deps Docker->>Docker: Runner stage: accept SERVICE_VERSION arg Docker->>Docker: Set ENV SERVICE_VERSION=${SERVICE_VERSION} Docker->>Container: Start container with env var Container->>Container: Read process.env.SERVICE_VERSION Container->>Logger: createServiceLogger({version: VERSION}) Logger->>Logger: Log with unique build identifierSummary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.