Missed Team ’24? Catch up on announcements here.

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

Using GitVersion with BitBucket Cloud Pipelines

David Keaveny March 28, 2022

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 https://gitversion.net/docs/usage/cli/installation) 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
Atlassian Team members are employees working across the company in a wide variety of roles.
March 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.

clone:
  depth: full

You can also check this page for more information.

Hope it helps and let me know how it goes.

Regards,
Mark C

David Keaveny March 30, 2022

Hi Mark, thanks for your reply.

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

image: mcr.microsoft.com/dotnet/sdk:6.0

clone:
  depth: full

pipelines:
  default:
  - step:
    name: Version
    script:
      - export PATH="$PATH:/root/.dotnet/tools"
      - export GIT_BRANCH=$BITBUCKET_BRANCH
      - 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
Atlassian Team members are employees working across the company in a wide variety of roles.
March 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.

Regards,
Mark C

David Keaveny March 30, 2022

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" mcr.microsoft.com/dotnet/sdk:6.0

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": "0.1.0.0",
"AssemblySemFileVer": "0.1.0.0",
"FullSemVer": "0.1.0-try-versioning-again.130",
"InformationalVersion": "0.1.0.130",
"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
Atlassian Team members are employees working across the company in a wide variety of roles.
March 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.

Regards,
Mark C

Sean Elliott
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
July 12, 2022

Was there an answer to this? 

Mark C
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 12, 2022

Hi @SEA

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

You can check this links below for more information:


Regards,
Mark C

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events