fix: mismatched image tags causing ImagePullBackOff

[amdove]

• fix: incorrect repository name leads to ImagePullBackOff after latest fix
• update tag format and tagged releases

[claude]

Claude finished @amdove's task —— View job

---

Review of PR #108

• Gather context and read review guidelines
• Read diff and changed files
• Analyze changes
• Post review

---

dist/chart/values.yaml — Repository name fix

The fix from posit/team-operator → posit/ptd-team-operator is correct. This aligns with what build.yml actually pushes to Docker Hub (line 249 of build.yml). This is clearly the root cause of the ImagePullBackOff.

---

.github/workflows/release.yml — Version prefix and Docker tagging

1. v prefix on version and appVersion (line 55)

Adding the v prefix means appVersion in Chart.yaml becomes e.g. v1.17.0. The manager template defaults the image tag to .Chart.AppVersion, so pods will pull posit/ptd-team-operator:v1.17.0. The new tag-docker-release job creates that tag, so it will exist — but note the dependency: if tag-docker-release fails, any fresh Helm install will get ImagePullBackOff again.

Also worth verifying: adding v to the Helm chart version field (not just appVersion) means chart versions become v1.17.0 instead of 1.17.0. While technically valid SemVer, the v prefix is unconventional for Helm charts. Confirm that downstream consumers — helm package, OCI registry push, helm install, and the notify-ptd workflow — all handle the v prefix correctly.

2. Race condition / no-release edge case (lines 71–74)

needs: release with if: needs.release.result == 'success' doesn't distinguish between "released a new version" and "ran successfully but no release was needed" (e.g., no releasable commits). In the latter case, this job would re-tag latest with whatever the most recent existing tag is — a no-op at best, but potentially confusing in logs. Consider having the release job output whether a new version was actually published and gating on that.

3. latest tag assumption (lines 100–108)

The job pulls :latest and re-tags it, which assumes latest corresponds to the just-released code. However, build.yml pushes latest on every push to main — including the chore(release) commit created by semantic-release. That commit changes Chart.yaml (not in paths-ignore), so build.yml will fire again and push a new latest. Depending on timing, tag-docker-release could tag either the pre-release or post-release latest.

The binary should be functionally identical either way, but a more robust approach would be to tag by image digest rather than relying on :latest.

4. package-helm interaction (line 55)

The package-helm job will now use v-prefixed versions for Helm chart packaging (e.g., team-operator-v1.17.0.tgz). The notify-ptd job passes this version to ptd via --field version=.... Make sure the downstream update-team-operator-version.yml workflow handles the v prefix.

---

Summary

The values.yaml fix is correct and necessary. The new tag-docker-release job is a reasonable approach to ensure versioned Docker tags exist. The main concerns are around edge cases (no-release runs, latest timing) and the v prefix propagating through Helm chart versions and downstream workflows.