fix: release workflow show version - #2278
Conversation
WalkthroughThe changes centralize version determination in the CI/CD release workflow by adding a "Determine Version" step that computes version via Changes
Sequence DiagramsequenceDiagram
actor Release as Release Trigger
participant GHA as GitHub Actions
participant Build as Build Step
participant Env as Environment
participant Binary as Compiled Binary
participant Init as InitEnv()
Release->>GHA: Trigger release workflow
GHA->>GHA: Determine Version (git describe --tags)
GHA->>Env: Export VERSION to GITHUB_ENV
GHA->>Build: Build with $VERSION available
Build->>Build: Frontend/Backend build (reference $VERSION)
Build->>Binary: Embed version info
Binary->>Init: Binary execution
Init->>Env: Read VERSION variable
Env-->>Init: Return VERSION value
Init->>Init: Assign to Version global
Init-->>Binary: Version now available for display
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 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: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/release.yml (1)
47-47: Update ldflags to use the full module path on lines 47, 52, 93, and 135.The
go.moddeclaresmodule github.com/QuantumNous/new-api, but all four build commands use the shortened path-X 'new-api/common.Version=$VERSION'. In Go, the-Xflag requires the exact full module path as declared ingo.mod. When the path doesn't match, the flag silently fails and the version is not set in the binary.Correct all four instances to:
-X 'github.com/QuantumNous/new-api/common.Version=$VERSION'This directly resolves the issue where the binary version was not being set at build time.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/release.yml(6 hunks)common/init.go(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
common/init.go (1)
common/constants.go (1)
Version(13-13)
🔇 Additional comments (2)
.github/workflows/release.yml (2)
25-28: LGTM! Centralized version determination is a good approach.The "Determine Version" step correctly computes the version using
git describe --tagsand exports it toGITHUB_ENV, making it available for subsequent steps. This eliminates redundant version computation and ensures consistency between frontend and backend builds.Also applies to: 70-73, 113-116
38-38: LGTM! Frontend version alignment is good.The frontend builds now use the centralized
$VERSIONvariable viaVITE_REACT_APP_VERSION=$VERSION, ensuring consistent version display between frontend and backend.Also applies to: 84-84, 126-126
| envVersion := os.Getenv("VERSION") | ||
| if envVersion != "" { | ||
| Version = envVersion | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
Question: Is the runtime VERSION environment variable override necessary?
The workflow changes set the version at build time using go build -ldflags "-X 'new-api/common.Version=$VERSION'", which should embed the version string directly into the binary. This runtime environment variable check appears redundant if the ldflags approach is working correctly.
Consider:
- If ldflags is working, this runtime override is unnecessary and could cause confusion (users might think they can override the version by setting a VERSION env var at runtime)
- If ldflags isn't working, the root cause should be fixed rather than adding a runtime workaround
- Mixing build-time and runtime version setting mechanisms adds complexity
Please verify:
- That the ldflags approach correctly embeds the version (check the module path
new-api/common.Versionmatches your go.mod module declaration - see next comment) - Whether this runtime override serves a specific purpose beyond the reported issue
🏁 Script executed:
#!/bin/bash
# Verify the module path in go.mod to ensure ldflags target is correct
cat go.mod | head -n 5Length of output: 77
The runtime VERSION override is necessary because the workflow's ldflags command uses an incorrect module path.
The workflow sets the version using -X 'new-api/common.Version=$VERSION', but your go.mod declares the module as github.com/QuantumNous/new-api. The ldflags command must use the full module path, so it should be:
-X 'github.com/QuantumNous/new-api/common.Version=$VERSION'
Without this correction, the build-time flag substitution fails silently, and the version remains at the default "v0.0.0". The runtime environment variable override in common/init.go is a valid workaround—but the root cause should be fixed in your workflow configuration.
Fix the workflow first, then reassess whether the runtime override is still needed.
🤖 Prompt for AI Agents
In common/init.go around lines 33 to 36, the current code applies a runtime
VERSION override which masks an incorrect ldflags module path used at build
time; update your CI/workflow build step to set the -X ldflag to the full module
path (e.g. -X 'github.com/QuantumNous/new-api/common.Version=$VERSION') so Go's
linker can substitute the build-time Version variable correctly, then remove or
reevaluate the need for the environment-based override in common/init.go after
confirming the build-time substitution works.
fix: release workflow show version
2 participants
fix #2242
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.