fix(deploy): give production telemetry a real version and environment

[kl3inIT]

Found by verifying phase 1 on the server instead of stopping at "the tests pass".

The good news first

The exporter warning is gone. Four minutes after 88c35cc deployed to ZM:

=== orgmemory-api-1 ===
  OtlpMeterRegistry publish failures: 0
  any localhost:4318 mention: 0
  ERROR lines: 0
  provider prompt-leak signatures: 0
=== orgmemory-worker-1 ===   (same)

Before this, each service logged that once a minute. ProviderLoggingBoundaryVerifier also passed against the real configuration rather than only under test — the applications started and reported healthy.

What the check found

Neither ORGMEMORY_SERVICE_VERSION nor ORGMEMORY_DEPLOYMENT_ENVIRONMENT was set on the containers:

$ docker inspect -f '{{range .Config.Env}}...' orgmemory-api-1 | grep -E 'ORGMEMORY_(SERVICE_VERSION|DEPLOYMENT_ENVIRONMENT)='
SPRING_PROFILES_ACTIVE=prod        # ← that is all that matched

So the resource attributes I added in #138 fell back to their local defaults, and production was reporting deployment.environment.name=local. A collector would have labelled the production deployment as a developer's laptop.

That is worse than the attribute being absent. Absent is visibly missing; wrong looks like data.

The fix

deploy.sh pins ORGMEMORY_SERVICE_VERSION to the released commit in the same rewrite that pins the image tags. They are written together deliberately — a service.version that lags the running image is worse than none at all, and the only way to guarantee they agree is to derive both from the same value in the same place. The function is renamed replace_image_references → pin_release_values since it no longer only handles images.

The production compose sets the environment explicitly rather than deriving it from the Spring profile, so the value a collector sees is readable in the file that deploys it.

Verification

bash -n on the script; the compose merge-key expansion checked by parsing the file and reading the resolved api and worker environments, since these values arrive through a YAML anchor and a silent anchor mistake would look exactly like the bug being fixed. Both resolve to production.

The next deployment is what proves the version pin end to end; that is stated in the plan rather than claimed here.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@kl3inIT, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 11 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: d42d667e-3cd2-4c21-a9f5-fc91526129ca

📥 Commits

Reviewing files that changed from the base of the PR and between 88c35cc and 3a18aa8.

⛔ Files ignored due to path filters (1)

• docs/increments/active/2026-07-29-observability-pipeline/plan.md is excluded by !docs/**

📒 Files selected for processing (3)

• infrastructure/deployment/compose.production.yaml
• infrastructure/deployment/production.env.example
• infrastructure/deployment/scripts/deploy.sh

---

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