Build using existing working copy doesn't fetch tags correctly

[ivovh]

I'm trying to build code that lives at a certain tag in the git repository. When creating a new working copy this works fine:

Unfortunately, when the working copy is already there it doesn't work:

It seems like the tags aren't fetched properly. If I use git fetch -tv instead of git fetch -v it does work. We're using agent v3.0-beta3.

[sj26]

Ah, this is a tricky one. Tags!

We can't use the --tags argument because we need to support git versions before it was introduced.

Here's the code path which seems to be running in your screenshot:

https://github.com/buildkite/agent/blob/v3.0-beta.3/agent/bootstrap.go#L942-L953

It looked like fetching a tag will work using the first attempted checkout, but because it's not mapped to the same ref locally (because it's a tag) it can't be checked out using its' symbolic name. It would work fine if we checked out the FETCH_HEAD instead.

Can you change your commit in however you're triggering this build to be HEAD instead of the tag name? That should make it use this code path which should work:

https://github.com/buildkite/agent/blob/v3.0-beta.3/agent/bootstrap.go#L934-L937

In the mean time I'll see if I can patch this to detect when a single commit fetch succeeds and use the FETCH_HEAD in that case as well.

[ivovh]

Can you change your commit in however you're triggering this build to be HEAD instead of the tag name?

Unfortunately this isn't possible. We trigger the build from Phabricator. Once a diff (it's kind of like a versioned PR) is created, the code is uploaded to a certain tag belonging to the diff id. Each update will be tagged with a new diff id. The actual commit hash is not saved anywhere as far as I know.

[mgood]

@ivovh you may be interested to know Phabricator is adding an extension for Buildkite support: https://secure.phabricator.com/T12173

I ran into this same issue trying to integrate them, though you don't need to know the commit hash to use the suggestion from @sj26. You can use the tag name as the "branch" and HEAD as the commit, like this and it will check things out correctly:

{
    "commit": "HEAD",
    "branch": "phabricator/diff/1234",
    "message": ""
}

[lox]

Can this be closed @sj26?

[sj26]

@lox I think we worked around this with BUILDKITE_REFSPEC, so I think this can be closed. @ivovh please let us know if this is still a problem and we'll re-investigate. :-)

[felixfbecker]

I am seeing the same problem trying to use semantic-release with Buildkite. It determines the last release from the git tags, but doesn't detect any git tags, so always tries to publish v1.0.0. I'm afraid I don't understand the workaround proposed here. How could I solve this?

[sj26]

@felixfbecker you should add a git fetch --tags into your script before creating the release. Buildkite tries to optimise fetching enough git history to run the current build. If you want more history then you should run a manual fetch. :-)

[lox]

@sj26 would you consider accepting a patch to make git fetch --tags the default given it's now widely supported? I've seen this surprise a lot of folks.