feat: log version on startup

[darksworm]

Summary by CodeRabbit

• New Features
  • The application now embeds its release version in builds.
  • Startup logs now display the running application version.
• Bug Fixes
  • Published container builds now correctly pass the release version into the application.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: 12e5337a-4bad-4d16-b384-e1c471640c19

📥 Commits

Reviewing files that changed from the base of the PR and between 788c6be and a0e5e73.

📒 Files selected for processing (4)

• .github/workflows/publish-image.yml
• Dockerfile
• main.go
• main_test.go

Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review.

---

Walkthrough

The release workflow passes its tag as a Docker build argument. The Dockerfile embeds that value in the Go binary. The application logs the version at startup, with tests validating the info message.

Changes

Versioned startup logging

Layer / File(s)	Summary
Build-time version injection .github/workflows/publish-image.yml, Dockerfile, main.go	The release workflow passes VERSION to Docker Bake. The Dockerfile links VERSION into main.version, which defaults to dev.
Startup version logging main.go, main_test.go	main logs the version before argument parsing. The test verifies the exact info message and confirms that no error message is emitted.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to a0e5e

Release images now embed their release tag and log it at startup, while local builds retain a dev version. The version flow and startup message are covered, with no remaining merge-blocking risk.

Sequence Diagram(s)

sequenceDiagram
  participant PublishWorkflow
  participant DockerBake
  participant Dockerfile
  participant Doormouse
  participant StdLogger
  PublishWorkflow->>DockerBake: Pass release tag as VERSION
  DockerBake->>Dockerfile: Provide VERSION build argument
  Dockerfile->>Doormouse: Embed VERSION in main.version
  Doormouse->>StdLogger: Log startup version before argument parsing

Loading

🚥 Pre-merge checks | ✅ 4 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 3 functions across 2 files. (2 skipped: 2…	Write docstrings for the functions missing them to satisfy the coverage threshold.
Tests	⚠️ Warning	The added test only calls logStartup directly. It verifies the message format and Info level, but it does not verify that main calls logStartup or that the Docker/workflow version reaches the …	Add an integration-level test for the startup path. Use a testable startup function or execute a built binary with -ldflags=-X main.version=2.1.0, then assert the startup log contains the release version before argument/configuration hand…

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: logging the application version during startup.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

Full details: Docstring Coverage

Explanation

Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 3 functions across 2 files. (2 skipped: 2 unsupported.)

Full details: Tests

Explanation

The added test only calls logStartup directly. It verifies the message format and Info level, but it does not verify that main calls logStartup or that the Docker/workflow version reaches the binary. The test would pass if startup logging were removed or if release builds still used dev. The changed startup and version propagation paths therefore lack coverage of the feature's observable behavior.

Resolution

Add an integration-level test for the startup path. Use a testable startup function or execute a built binary with -ldflags=-X main.version=2.1.0, then assert the startup log contains the release version before argument/configuration handling. Also add validation for the Dockerfile and publish workflow wiring, or otherwise make the integration test fail when VERSION is not passed through to the release binary.

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/startup-version-log

---

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.}