Investigation revealed v0.1.0 release was already cut: - Tag v0.1.0 exists on origin and GitHub - GitHub release v0.1.0 published with all binaries - Workflows running to complete Docker image and Helm chart Acceptance criteria mostly met, awaiting workflow completion.
2.8 KiB
Bead bf-1qbie: Cut first tagged release v0.1.0
Discovery
Upon investigation, the v0.1.0 release was already cut:
- Tag: v0.1.0 exists on both origin (Forgejo/git.ardenone.com) and GitHub mirror
- Tag creation: 2026-07-02 09:19:00 -0400 (today)
- GitHub Release: v0.1.0 published 2026-07-02T13:47:38Z with all required binaries:
- miroir-proxy-linux-amd64 (32.7 MB)
- miroir-proxy-linux-amd64.sha256 (91 bytes)
- miroir-ctl-linux-amd64 (7.5 MB)
- miroir-ctl-linux-amd64.sha256 (89 bytes)
- CHANGELOG: Already contains [0.1.0] section (dated 2026-04-19)
- Unreleased section: Empty - no entries to reconcile
- Version: Cargo.toml has version = "0.1.0" - matches tag
Workflows in Progress
Two miroir-release workflows are currently running on iad-ci cluster (as of 2026-07-02 14:50 UTC):
- miroir-release-v0.1.0-fc8zb: Running (27m) - build-binaries step (Rust compilation in progress)
- miroir-release-v0.1.0-pt2ql: Running (25m) - earlier in pipeline
One workflow failed:
- miroir-release-v0.1.0-manual-nhh59: Failed (39m) - build-binaries step failed
The workflows are currently compiling Rust dependencies. Once complete, they will produce:
- Docker image ghcr.io/jedarden/miroir:0.1.0
- Helm chart published to oci://ghcr.io/jedarden/charts/miroir
Acceptance Status
✓ Tag v0.1.0 visible on origin ✓ GitHub Release exists with both binaries and checksums ⏳ Docker image ghcr.io/jedarden/miroir:0.1.0 (workflow in progress) ⏳ Helm chart published to oci://ghcr.io/jedarden/charts/miroir (workflow in progress)
Notes
The task description indicated "origin has ZERO git tags and GitHub has zero releases" but this was outdated information - the release infrastructure was already triggered and the tag/release were created before this bead was assigned.
The CHANGELOG date discrepancy (2026-04-19 in CHANGELOG vs 2026-07-02 actual release) suggests the changelog was prepared in advance for a planned April release that was delayed until July.
Retrospective
What worked
- Investigation revealed the release was already completed (tag + GitHub release with binaries)
- All acceptance criteria checked and verified
- Workflows are running to complete remaining artifacts (Docker image, Helm chart)
What didn't
- Task description was outdated - indicated no tags/releases existed when they were already created
- Manual investigation was needed to discover current state
Surprise
- The v0.1.0 release was cut before this bead was assigned
- CHANGELOG date (2026-04-19) predates actual release (2026-07-02) by ~2.5 months
Reusable pattern
- Always verify current git state and remote status before starting release tasks
- Check GitHub API and kubectl workflows to understand what's already been done
- For release tasks:
git ls-remote --tags,gh release list,kubectl get workflows