Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Using GitVersion with BitBucket Cloud Pipelines

I am currently using Pipelines to build some applications hosted in BitBucket Cloud; however I am having problems when trying to configure GitVersion to generate semantic version numbers for each build.

If I set up and install GitVersion (using the .NET CLI tool as per locally and then run it, then the tool works as expected and calculates the appropriate version number. However, if I run it as a step in my Pipeline, then it errors with the message 

Gitversion could not determine which branch to treat as the development branch (default is 'develop') nor release-able branch (default is 'main' or 'master'), either locally or remotely. Ensure the local clone and checkout match the requirements or considering using 'GitVersion Dynamic Repositories'

Is there anything unusual in the way that Pipelines retrieves the source code to be built from the repo that would cause this sort of error? Do I need to force Pipelines to clone the entire repository, and if so, how do I do that?

1 answer

0 votes
Mark C Atlassian Team Mar 29, 2022

Hi @David Keaveny

Thank you for reaching out to the community.

By default, Bitbucket Cloud Pipelines clones the specific branch of a repository with the top 50 commits.
You'll notice this in the "Build setup" phase of a Pipelines build.
There's the git clone command with the branch and depth options.

git clone --branch="master" --depth 50 ....

It seems the GitVersion needs the full clone of your repository.
For this, you can enforce Pipelines to do a full clone by specifying the configuration below in your YAML file.

  depth: full

You can also check this page for more information.

Hope it helps and let me know how it goes.

Mark C

Hi Mark, thanks for your reply.

I added the extra setting to my bitbucket-pipelines.yml, which now looks like this:


  depth: full

  - step:
    name: Version
      - export PATH="$PATH:/root/.dotnet/tools"
      - dotnet tool install --global GitVersion.Tool --version 5.*
      - dotnet-gitversion /diag /output buildserver

but it doesn't change the error message.

Mark C Atlassian Team Mar 30, 2022

Hi @David Keaveny

Could you try testing this locally in a Docker container and see if you're also experiencing the same issue there?
You can check this link for more information on how you can test your Pipelines build locally in a Docker container. - Debug pipelines locally with Docker

Let me know how it goes.

Mark C

Hi @Mark C 

I've tried as you suggested; I ran the container as follows:

docker run -it --volume=/C/Code/MyProject:/code --workdir="/code"

which drops me into the container at the command line; I then run the commands as they are in the bitbucket-pipelines.yml file:

export PATH="$PATH:/root/.dotnet/tools"
export GIT_BRANCH="feature/try-versioning-again"
dotnet tool install --global GitVersion.Tool --version 5.*
dotnet-gitversion /diag /output buildserver

and GitVersion produces the output that I would expect to see:

"Major": 0,
"Minor": 1,
"Patch": 0,
"PreReleaseTag": "try-versioning-again.130",
"PreReleaseTagWithDash": "-try-versioning-again.130",
"PreReleaseLabel": "try-versioning-again",
"PreReleaseLabelWithDash": "-try-versioning-again",
"PreReleaseNumber": 130,
"WeightedPreReleaseNumber": 30130,
"BuildMetaData": null,
"BuildMetaDataPadded": "",
"FullBuildMetaData": "Branch.feature-try-versioning-again.Sha.e97d83c3e60e4b44ef31a366d2a8f228d8a4b046",
"MajorMinorPatch": "0.1.0",
"SemVer": "0.1.0-try-versioning-again.130",
"LegacySemVer": "0.1.0-try-versioning-ag130",
"LegacySemVerPadded": "0.1.0-try-versioning-a0130",
"AssemblySemVer": "",
"AssemblySemFileVer": "",
"FullSemVer": "0.1.0-try-versioning-again.130",
"InformationalVersion": "",
"BranchName": "feature/try-versioning-again",
"EscapedBranchName": "feature-try-versioning-again",
"Sha": "e97d83c3e60e4b44ef31a366d2a8f228d8a4b046",
"ShortSha": "e97d83c",
"NuGetVersionV2": "0.1.0-try-versioning-a0130",
"NuGetVersion": "0.1.0-try-versioning-a0130",
"NuGetPreReleaseTagV2": "try-versioning-a0130",
"NuGetPreReleaseTag": "try-versioning-a0130",
"VersionSourceSha": "14482456eb23a5e1df3dcf8ee5c03f7b4fe61b40",
"CommitsSinceVersionSource": 130,
"CommitsSinceVersionSourcePadded": "0130",
"UncommittedChanges": 1235,
"CommitDate": "2022-03-30"

So I'm guessing there's still something funny in the way that BitBucket is cloning the repo, even when I've added the clone depth full setting.

Mark C Atlassian Team Mar 31, 2022

Hi @David Keaveny

Thanks for trying it out.

For us to investigate the issue further, I went ahead and created a support ticket on your behalf.

You should receive an email notification about it and we can continue our conversation there.

Mark C

Was there an answer to this? 

Mark C Atlassian Team Jul 12, 2022


This was fixed by the author of GitVersion with the released version 5.10.1.

You can check this links below for more information:

Mark C

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events