An unexpected error occurred: Could not find a 'develop' or 'master' branch, neither locally nor remotely. branches are -> pull request branches #912
Comments
ashtonian
changed the title
ashtonian
changed the title
|
I'm using teamcity and the git plugin, I logged into the cloned repository and ran git branch and it returns: as thats the bitbucket remote. Makes sense that gitversion can't find master then. It's odd though because this only happens occasionally. Not sure what to do to fix it. |
|
I'm getting the same issue here. We're porting our projects from Bamboo into TeamCity and use GitVersion with GitFlow |
|
Are you able to figure out how the pull request branches are checked out by git? What GitVersion configuration do you have (are you using |
|
It looks like an issue with TeamCity and they way it pulls down the repo to the build agent. it doesn't do a full fetch. I've fixed this for us by adding an extra PowerShell build step that simply calls 'git fetch'. |
|
@msnelling Sounds like a sneaky work-around, but I'm glad it works. I wish we could find a way for GitVersion to circumvent this so users of it didn't have to circumvent it themselves, though. Ideas, @GitTools/developers? |
|
Interesting.. The issue is https://github.com/GitTools/GitVersion/blob/master/src/GitVersionCore/BuildServers/TeamCity.cs#L44 If you setup GitVersion according to docs this will happen. Looks like we can't skip the fetch, so that override has to be removed unfortunately :( |
|
I have the same issue with VSTS with two separate scenarios.
We seem to be hitting this using either the GitVersion build step or GitVersionTask package in a proj. Is there any workaround that we should apply to fix this? |
|
@roryprimrose workaround for VSTS is at #993 |
|
I hit the same problem and git fetch -all solved it |
|
My 2 cents: As the comment in the code states, this error needs a much more meaningful error message with suggestions for action to resolve. (I'd create a PR myself but I don't really understand the issue or its resolution.) I think we're seeing more and more people bump into this issue - Who knows how many others give up on GitVersion before resolving through this page? :| |
|
Actually it is also intermittent in my case. It did not work. Then I added git fetch -all and it worked. Once. Then it failed twice.
|
|
The workaround suggested in #993 worked for one build but other builds failed wanting a username. I updated the build workflow to be surrounded by the ioz build steps and they were all good. See https://marketplace.visualstudio.com/items?itemName=ioz.vsts-git-build-tasks |
|
Hmmm, there was a 3.4.33-dawops.20 tag in the source control. I can imagine GitVersion added it and this is why the build worked once. I've removed it and the build works fine now but the version is 3.4.6-dawops.22. Not sure why but this is a problem for Monday :) |
|
I haven't used mainline mode with release branches yet. It seems that the issue has just started happening on TeamCity, can someone let me know: Version of teamcity and agent or server checkout, also the GitVersion.yml config and what your fetch refspec for your build is? In VSTS this happens because the build agent initialises and fetches the git repo with a refspec of +refs/pulls//merge:refs/pulls//merge, which means that only the PR ref is pulled down, not master or develop, so not branch config can be inherited. |
GitVersion never tags, maybe was the build server? |
|
@JakeGinnivan thanks for having a look. These are our details: From what you are saying fetching develop and master is the way it needs to be done ? |
|
Yeah, just do a fetch. Make sure you upgrade to v4-beta.7, it fixes a nasty bug where if you do a second fetch to work around this issue and the branch you are building moves on it can checkout the remote HEAD, so you build a different commit =/ |
|
I will try and put some time into fixing properly, but lots on at the moment. |
|
Thanks |
|
I'm not sure it's related, but since it yields the same exception, I've found Even after doing @JakeGinnivan Ideas? |
|
From my message in gitter: Yep, after running So the fix is run |
|
@pawelpabich can you figure out what git command TeamCity is running in your case, each build server will require different treatment. |
|
@JakeGinnivan Doing LibGit2Sharp.LibGit2SharpException: ref 'refs/remotes/origin/feature/mkdocs-build' doesn't match the destination
at LibGit2Sharp.Core.Ensure.HandleError (Int32 result) <0x409cc4f0 + 0x00127> in <filename unknown>:0
at LibGit2Sharp.Core.Ensure.ZeroResult (Int32 result) <0x409347c0 + 0x0001f> in <filename unknown>:0
at LibGit2Sharp.Core.Proxy.git_refspec_rtransform (IntPtr refSpecPtr, System.String name) <0x409cc230 + 0x00062> in <filename unknown>:0
at LibGit2Sharp.Remote.FetchSpecTransformToSource (System.String reference) <0x409cc160 + 0x00080> in <filename unknown>:0
at LibGit2Sharp.BranchUpdater.GetUpstreamInformation (System.String canonicalName, System.String& remoteName, System.String& mergeBranchName) <0x409cbb90 + 0x0019a> in <filename unknown>:0
at LibGit2Sharp.BranchUpdater.SetUpstream (System.String upstreamBranchName) <0x409cba20 + 0x00058> in <filename unknown>:0
at LibGit2Sharp.BranchUpdater.set_TrackedBranch (System.String value) <0x409cb980 + 0x00064> in <filename unknown>:0
at GitTools.Git.GitRepositoryHelper+<>c__DisplayClass8_1.<CreateOrUpdateLocalBranchesFromRemoteTrackingOnes>b__2 (LibGit2Sharp.BranchUpdater b) <0x409cb950 + 0x0001f> in <filename unknown>:0
at LibGit2Sharp.BranchCollection.Update (LibGit2Sharp.Branch branch, System.Action`1[] actions) <0x409cb710 + 0x0009d> in <filename unknown>:0
at GitTools.Git.GitRepositoryHelper.CreateOrUpdateLocalBranchesFromRemoteTrackingOnes (LibGit2Sharp.Repository repo, System.String remoteName) <0x409c8aa0 + 0x007cc> in <filename unknown>:0
at GitTools.Git.GitRepositoryHelper.NormalizeGitDirectory (System.String gitDirectory, GitTools.Git.AuthenticationInfo authentication, Boolean noFetch, System.String currentBranch) <0x40984430 + 0x0021e> in <filename unknown>:0
at GitVersion.GitPreparer.Initialise (Boolean normaliseGitDirectory, System.String currentBranch) <0x40938560 + 0x00069> in <filename unknown>:0
at GitVersion.ExecuteCore.ExecuteGitVersion (System.String targetUrl, System.String dynamicRepositoryLocation, GitVersion.Authentication authentication, System.String targetBranch, Boolean noFetch, System.String workingDirectory, System.String commitId, GitVersion.Config overrideConfig, Boolean noCache) <0x409358e0 + 0x0018b> in <filename unknown>:0
at GitVersion.SpecifiedArgumentRunner.Run (GitVersion.Arguments arguments, IFileSystem fileSystem) <0x40935220 + 0x001c4> in <filename unknown>:0
at GitVersion.Program.VerifyArgumentsAndRun () <0x408fd1e0 + 0x00442> in <filename unknown>:0 |
|
@JakeGinnivan sure. It looks like it fetches only the feature branch. {15:28:52] : [VCS Root: Calamari] The .git directory is missing in 'Z:\BuildAgent\work\14ffc968155e4956'. Running 'git init'... |
|
We are also seeing this with Would https://gitversion.readthedocs.io/en/latest/more-info/dynamic-repositories/ help? they feel expensive if the agent is clean each time. |
|
Note; |
|
Anyone got a workaround for when using (uploaded) SSH key for authentication in TeamCity?
it fails on authentication/permissions, so I have to change the VCS roots back to username/password authentication to get this working. I haven't observed this behaviour before upgrading from TC 9.1.7 -> 10.0.4, but that may be coincidental. |
|
Is there any further update on this issue? We're using GitVersion with TeamCity and have encountered this issue. I can't see any permanent workaround or fix in this thread? |
|
This is a recurring issue, the fix is to fetch all the remote changes before invoking gitversion, and if it's a shallow clone using The action for me, or anyone who wants to jump in is to detect this issue proactively in GitVersion, try to resolve automatically and if it fails give a good error message which explains the issue and how to resolve. It is also becoming more of an issue as more build systems do shallow clones and other git optimisations to speed up the builds. |
|
I'm slow and just noticed this on my end after updating TeamCity. When the branch is not master or develop this happens (probably because of the shallow clone). Wonder if there is a toggle in TC for non-shallow clone. FOUND IT! This is how you do it:
If you do it in Root you won't have to keep writing the same parameter. |
|
@tofutim: Awesome find! It would be good to have this documented. Would you like to submit a PR that adds this note to the TeamCity build server documentation? An added bonus would be to somehow detect this within GitVersion and as @JakeGinnivan suggests, provide a good error description on what to do to fix the problem. |
|
Might TeamCity bug TW-24878 be the issue at hand here? With version 10.0.4 of TeamCity, the configuration parameter |
|
@asbjornu one issue with this setting in teamcity is that it doesn't work with github pull requests as they are not under |
|
@jonnii: So TeamCity does not fetch all heads beneath |
|
@asbjornu exactly, but it doesn't fetch the PR at all - the feature is just broken. I've managed to get this all to work by using |
|
@asbjornu I don't think it's teamcity 10 issue. We started having issues once we upgraded to 2017. Before, in TC 10 we did not have any problems with running gitversion. The upgrade was definitely the cause. |
|
This workaround fixed the issue for us: https://youtrack.jetbrains.com/issue/TW-24878 |
|
@tofutim you have been a life saver. Can't thank you enough. |
|
As I mentioned |
|
I'm using the Bitbucket pipeline, to build an ASP.NET Core project using the GitVersionTask. I want to build branches which are neither named develop nor master. |
|
Similar problem as above. I deleted the master branch in my repo and set the default branch to |
|
@thomaswr Did you find any solution? |
|
@richagarg0731 |
|
teamcity.git.fetchAllHeads: true fixed for me |
and others
I get a random issue with GitVersion sometimes and it just crashes. It seems to fix it self somehow and I'm not sure what the problem is. Seems to only occur with pull requests.
The text was updated successfully, but these errors were encountered: