fix(release): also move the latest docker manifest on versioned releases#69
Conversation
|
Warning Review limit reached
Next review available in: 58 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
WalkthroughThis change updates the `.goreleaser.yml` release configuration by adding a new `docker_manifests` entry for the `latest` tag. The manifest targets `fleet:latest` and references existing `amd64`/`arm64` per-architecture image templates based on `DOCKER_TAG`. A `skip_push` condition is included to prevent pushing when `DOCKER_PUSH` is `"false"` or when `DOCKER_TAG` is already `"latest"`. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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 |
Dispatch-triggered releases pushed only the versioned image tags, so the latest tag froze (last moved 2026-06-24) while dev environments track latest via Keel polling — dispatch-built images never reached dev. Publish a second manifest for latest from the same per-arch images, skipped on push-triggered builds where DOCKER_TAG is already latest. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
f49d3bf to
60048e0
Compare
Description
Dispatch-triggered releases (
workflow_dispatch→DOCKER_TAG=<version>, seerelease.yml:204) push only the versioned image tags (0.2.9,0.2.9-amd64,0.2.9-arm64). Thelatestmanifest is only produced whenDOCKER_TAGitself islatest(push-triggered builds), so the tag froze on 2026-06-24 while versioned releases kept shipping.Dev environments are built around
latest:values-dev.yamlpinsimageTag: latestwith Keel poll annotations. Withlatestfrozen, Keel never sees a digest change andkubectl rollout restartfaithfully re-pulls the same two-week-old image — dispatch-built images (including the 0.2.9 cpe.sqlite self-heal fix from #68) never reach dev.Fix: a second
docker_manifestsentry in.goreleaser.ymlthat publishesfleet:latestfrom the same per-arch images built for the versioned tag. It is skipped whenDOCKER_PUSH=falseor whenDOCKER_TAGis alreadylatest(would duplicate the first manifest).Improvements
.goreleaser.yml: publish thelatestmulti-arch manifest alongside the versioned one on dispatch releases; no extra builds — it references the already-pushed-amd64/-arm64images.Task
Follow-up to #68 / release 0.2.9 — unblocks dev (Keel +
imageTag: latest) from receiving dispatch-built images.🤖 Generated with Claude Code
Summary by CodeRabbit
latestmanifest so the published image now includes a stablelatesttag.latestis already being used or image pushing is disabled.