Fix the pull request hack needed to build pulls in TeamCity

[andreasohlund]

At the moment we can't figure out the branchname (name of the pull) from the git info so we have to add a build param to each build:

https://github.com/Particular/GitFlowVersion/blob/master/GitFlowVersion/TeamCity.cs#L20

This is a maintenance pain!

@nulltoken any ideas on how we can solve this? (doesn't seem like the git directory on the buildagent contains this info even though TC seems to capture it ok)

This is the ex from LibGit2Sharp we get

[src\NServiceBus.RabbitMQ\NServiceBus.Transports.RabbitMQ.csproj] UpdateAssemblyInfo
[08:23:27][UpdateAssemblyInfo] GitFlowVersionTask.UpdateAssemblyInfo
[08:23:27][GitFlowVersionTask.UpdateAssemblyInfo] Version not in cache. Calculating version.
[08:23:27]
[GitFlowVersionTask.UpdateAssemblyInfo] Error occurred: LibGit2Sharp.InvalidSpecificationException: An error was raised by libgit2. Category = Reference (InvalidSpecification).
The given reference name '(no branch)' is not valid
   at LibGit2Sharp.Core.Ensure.HandleError(Int32 result)
   at LibGit2Sharp.Core.Proxy.git_reference_lookup(RepositorySafeHandle repo, String name, Boolean shouldThrowIfNotFound)
   at LibGit2Sharp.ReflogCollection.GetEnumerator()
   at System.Linq.Enumerable.Last[TSource](IEnumerable`1 source)
   at GitFlowVersion.FeatureVersionFinder.FindFirstCommitOnBranch() in c:\Code\Particular\GitFlowVersion\GitFlowVersion\BranchFinders\FeatureVersionFinder.cs:line 61
   at GitFlowVersion.FeatureVersionFinder.FindVersion() in c:\Code\Particular\GitFlowVersion\GitFlowVersion\BranchFinders\FeatureVersionFinder.cs:line 21
   at GitFlowVersion.GitFlowVersionFinder.FindVersion() in c:\Code\Particular\GitFlowVersion\GitFlowVersion\GitFlowVersionFinder.cs:line 69
   at GitFlowVersion.VersionForRepositoryFinder.GetVersion(Repository repository) in c:\Code\Particular\GitFlowVersion\GitFlowVersion\VersionForDirectoryFinder.cs:line 18
   at GitFlowVersion.VersionCache.GetVersion(String gitDirectory) in c:\Code\Particular\GitFlowVersion\GitFlowVersion\VersionCache.cs:line 39
   at GitFlowVersionTask.UpdateAssemblyInfo.Execute() in c:\Code\Particular\GitFlowVersion\GitFlowVersionTask\UpdateAssemblyInfo.cs:line 57
[08:23:27][src\NServiceBus.RabbitMQ\NServiceBus.Transports.RabbitMQ.csproj] Project src\NServiceBus.RabbitMQ\NServiceBus.Transports.RabbitMQ.csproj failed.
[08:23:27][src\NServiceBus.RabbitMQ.sln] Project src\NServiceBus.RabbitMQ.sln failed.
[08:23:27][src\NServiceBus.RabbitMQ.sln.teamcity] Project src\NServiceBus.RabbitMQ.sln.teamcity failed.

Full build log:

http://builds.particular.net/viewLog.html?buildId=27764&buildTypeId=NServiceBusRabbitMQ_1Buil&tab=buildLog

[nulltoken]

@andreasohlund

At the moment we can't figure out the branchname (name of the pull) from the git info so we have to add a build param to each build:

https://github.com/Particular/GitFlowVersion/blob/master/GitFlowVersion/TeamCity.cs#L20
This is the ex from LibGit2Sharp we get

repo.Head returns the branch that HEAD points to.

• When HEAD is attached, Name will return the branch short name (eg . master)
• When HEAD is detached (ie. directly points to a commit), the returned Branch doesn't exist per se. Its Tip returns the commit that HEAD was pointing to, but its name will be (no name).

From what I've understood by peeking at your logs

• develop is properly checked out. And HEAD is attached because it's seen by JGit as a branch (starts with refs/heads/)

[10:02:43][VCS Root: GitHub.NServiceBus] Commit 'f3d07c815d3edb749c5f47d551d86d84b23328a8' is not found in repository. Running 'git fetch'...
[10:03:10][VCS Root: GitHub.NServiceBus] Checking out branch refs/heads/develop in GitHub.NServiceBus in Y:\BuildAgent\work\31f8c64a6e8a2d7c with revision f3d07c815d3edb749c5f47d551d86d84b23328a8

• Pull requests are checked out in detached mode. I figure this is because they live in the refs/pull/ namespace and not in the refs/heads one.

[08:45:04][VCS Root: GitHub.NServiceBus] Commit 'ee0d911625a2533b0b26a9c48271d00ddcc7b323' is not found in repository. Running 'git fetch'...
[08:45:32][VCS Root: GitHub.NServiceBus] Resetting GitHub.NServiceBus in C:\BuildAgent\work\31f8c64a6e8a2d7c to revision ee0d911625a2533b0b26a9c48271d00ddcc7b323

The build log that you linked against seems to originate from a pull request (Particular/NServiceBus.RabbitMQ#12). Strangely, pulls requests in the NServiceBus project seem to build fine (whereas they're also checked out in detached mode, making branch.CanonicalName return (no name)).

Thus, considering the code below, my guess would be that, for whatever reason, the environment variable isn't properly set in the NServiceBus.RabbitMQ build environment.

public static bool IsPullRequest(this Branch branch)
{
    return branch.CanonicalName.Contains("/pull/") || TeamCity.IsBuildingAPullRequest();
}

Few things I'm unsure about:

• When GitFlowVersionFinder cannot detect what kind of branch it's working with (which is what's happening when HEAD is detached), it assumes a FeatureBranch. Maybe should we spawn a different finder strategy, or a least cope with the potential detached state with an additional if (repo.Info.IsHeadDetached may be handy here).
• FeatureVersionFinder relies on the ref log and I that seems a bit weird in the TeamCity context. The ref log is fed through interactions with the repository (Commits, Resets, Rebases, ...). From the TeamCity perspective, it's a fresh clone, with no log.

[nulltoken]

"pull request hack" and "so we have to add a build param to each build"

Are you referring to the TeamCity.IsBuildingAPullRequest() method? Or is there another thing?

[andreasohlund]

correct, essentially we use TC to populate a env variable that we can read with the branch name. This is a maintenance nightmare. So it seems that TC it self can get the branch name but at the buildagent that info is lost

[nulltoken]

correct, essentially we use TC to populate a env variable that we can read with the branch name. This is a maintenance nightmare.

I'm not sure I understand the maintenance nightmare. Isn't this environment variable dynamically set by TC upon a build?

but at the buildagent that info is lost

It looks like some build agents can access it properly, though, can't they?

[andreasohlund]

No(at least I can't find an easy way) we have to manually promote it from a build property to a env variable for each build

Sent from my iPhone

On 15 nov 2013, at 15:49, nulltoken notifications@github.com wrote:

correct, essentially we use TC to populate a env variable that we can read with the branch name. This is a maintenance nightmare.

I'm not sure I understand the maintenance nightmare. Isn't this environment variable dynamically set by TC upon a build?

but at the buildagent that info is lost

It looks like some build agents can access it properly, though, can't they?

—
Reply to this email directly or view it on GitHub.

[nulltoken]

No(at least I can't find an easy way) we have to manually promote it from a build property to a env variable for each build

Oh! I didn't get that. The nightmare makes much more sense to me, now.

I may have an idea. Provided you can remotely access to the build agent, could you peek the state of the repo after the fetching is done? Are there any entries under .git/refs/?

If that's the case, then we may try and change GFW so that, when the HEAD is detached, it would enumerate all the repo.Refs entries, searching for the reference actually pointing to the commit the HEAD refers to. And then, update GitFlowVersionFinder so that it relies on the reference name.

[andreasohlund]

This build has the .git folder included in the artifacts:

http://builds.particular.net/viewLog.html?buildId=27955&buildTypeId=NServiceBusCore_Build&tab=artifacts#!1cig

Cheers!

On Fri, Nov 15, 2013 at 4:20 PM, nulltoken notifications@github.com wrote:

No(at least I can't find an easy way) we have to manually promote it from
a build property to a env variable for each build

Oh! I didn't get that. The nightmare makes much more sense to me, now.

I may have an idea. Provided you can remotely access to the build agent,
could you peek the state of the repo after the fetching is done? Are there
any entries under .git/refs/?

If that's the case, then we may try and change GFW so that, when the HEAD
is detached, it would enumerate all the repo.Refs entries, searching for
the reference actually pointing to the commit the HEAD refers to. And then,
update GitFlowVersionFinder so that it relies on the reference name.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/31#issuecomment-28576178
.

[nulltoken]

@andreasohlund Hmm.. The local .git repo doesn't contain the refs/pull/ namespace.

How about this?

• We retrieve the advertised refs from the remote repo (https://github.com/Particular/NServiceBus.git)
• We search among them which one points to the merge point
• We retrieve its name

[Fact]
public void FightingAgainstAndreasNightmare()
{
    // State that we can observe in TeamCity
    const string repoPath = @"D:\dev\NServiceBus_1._Build_4.3.0-PullRequest-1734_artifacts";
    string mergeSha;

    using (var repo = new Repository(repoPath))
    {
        Assert.True(repo.Info.IsHeadDetached);

        // Retrieve the commit pointed at by HEAD
        // This is a merge commit with two parents
        //  - The tip of the PR
        //  - The tip of the branch the PR targets
        mergeSha = repo.Head.Tip.Sha;
    }

    // -------------------------------
    // Resolving the Nightmare. Take 1
    // -------------------------------
    using (var repo = new Repository(repoPath))
    {
        var refs = repo.Network.ListReferences(repo.Network.Remotes.Single());

        var mergeRefs = refs.Where((r) => r.TargetIdentifier == mergeSha);
        Assert.Equal(1, mergeRefs.Count());

        Assert.Contains("/pull/", mergeRefs.Single().CanonicalName);
    }
}

[nulltoken]

So, in short the strategy would be:

• HEAD is attached
  • Use the name of the branch
• HEAD is detached.
  • List the remote refs
  • Find the ref pointing the the HEAD commit
  • Use the name of the reference

Consider not relying on the reflog as that wouldn't work in a TeamCity context.

[andreasohlund]

This is wonderful, should I try to work this into the code base or can I trick you into doing a pull?

[nulltoken]

I'm not sure I understand all the ways GFV is being used. However, I'll give it a try.