Yes, absolutely. This is a build that’s triggered by a tag filter in the first place. I’m working around the issue by using my own checkout commands where I run git fetch --all to pull all tags before checking it out. It’s a crude solution, but there’s absolutely no question that the tag does in fact exist.
so that Git is forced to create or update the tag name in the local repository. The existing line obviously works for most people, but this is something that depends on the git version.
Hi, I confirm that this bug is still around. Can you please fix this or at least, explain why this is not already fixed ? It seems like an easy patch for a nasty bug.
Hi, just to re confirm that the bug is still present. I’m trying to migrate from v1.0 in which we used to release after tags release-xxxx… But v2.0 seems not playing well with tags yet…
The job is triggered by a tag in github. Here the last lines from circleCI
if [ -n "$CIRCLE_TAG" ]
then
git reset --hard "$CIRCLE_SHA1"
git checkout -q "$CIRCLE_TAG"
elif [ -n "$CIRCLE_BRANCH" ]
then
git reset --hard "$CIRCLE_SHA1"
git checkout -q -B "$CIRCLE_BRANCH"
fi
git reset --hard "$CIRCLE_SHA1"
^D^DWarning: Permanently added the RSA host key for IP address '192.30.253.112' to the list of known hosts.
remote: Counting objects: 15, done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 15 (delta 6), reused 14 (delta 6), pack-reused 0
Unpacking objects: 100% (15/15), done.
From github.com:Geovation/refill
* tag release-test-4 -> FETCH_HEAD
HEAD is now at 9def7ac bump (#380)
error: pathspec 'release-test-4' did not match any file(s) known to git.
Exited with code 1