Problem
The release step in .buildkite/pipeline.yml resolves the version from git tag -l \v*' --sort=-v:refname | head -1. Since the releasestep may run on a **different Buildkite agent** than thetagstep, the freshly-created tag is missing from the local checkout — resulting inno tag found` and no GitHub release being created.
Root Cause
git tag -l only lists tags present in the local repository. Buildkite agents do shallow clones (--depth=50) and do not automatically fetch the tag that was just pushed by the tag step on another agent.
Fix Applied
Added a 3-tier fallback chain in the release step (.buildkite/pipeline.yml):
BUILDKITE_TAG — populated for tag-push-triggered builds (fast path).git fetch --tags origin + git tag -l — pulls remote tags into the local clone before listing them.git ls-remote --tags origin \v'`* — queries the remote directly as a final fallback (works regardless of local state).
All three tiers resolve the same tag: the one pushed by the tag step at git push origin "${VERSION}". Any should be sufficient; the multi-tier approach adds resilience against propagation delay or shallow clone edge cases.
Problem
The
releasestep in.buildkite/pipeline.ymlresolves the version fromgit tag -l\v*' --sort=-v:refname | head -1. Since thereleasestep may run on a **different Buildkite agent** than thetagstep, the freshly-created tag is missing from the local checkout — resulting inno tag found` and no GitHub release being created.Root Cause
git tag -lonly lists tags present in the local repository. Buildkite agents do shallow clones (--depth=50) and do not automatically fetch the tag that was just pushed by thetagstep on another agent.Fix Applied
Added a 3-tier fallback chain in the
releasestep (.buildkite/pipeline.yml):BUILDKITE_TAG— populated for tag-push-triggered builds (fast path).git fetch --tags origin+git tag -l— pulls remote tags into the local clone before listing them.git ls-remote --tags origin\v'`* — queries the remote directly as a final fallback (works regardless of local state).All three tiers resolve the same tag: the one pushed by the
tagstep atgit push origin "${VERSION}". Any should be sufficient; the multi-tier approach adds resilience against propagation delay or shallow clone edge cases.