arturcic on 5.3.6
$ git clone https://github.com/owner/repo.git owner/repo Cloning into 'owner/repo'... $ cd owner/repo $ git fetch origin +refs/pull/33/merge: From https://github.com/owner/repo * branch refs/pull/33/merge -> FETCH_HEAD $ git checkout -qf FETCH_HEAD
It looks like the branch being examined is a detached Head pointing to commit '4786479'. Without a proper branch name GitVersion cannot determine the build version.
@nmbro I took a quick look at the config that travis-ci reports to use: https://travis-ci.com/github/nmbro/travis-gitversion/jobs/356052758/config
and from the looks of it, it seems it doesn't respect that you use
git: depth: false (I don't know if this is something related to using travis-ci.com, as for my own repository on travis-ci.org it respects it), and from looking at the build output from that build it indeed uses a depth flag of 50: https://travis-ci.com/github/nmbro/travis-gitversion/jobs/356052758#L113
Try adding to your yaml file a call to
git fetch --unshallow, I believe this should then get gitversion to work for you (since the build didn't respect the git depth value).
@nmbro adding that in a PR don't help, travis (same with appveyor) don't use the yaml file from the pull request, but from the target branch.
So it would need to be added in the repository directly.
You can see the config used on that build here: https://travis-ci.com/github/nmbro/travis-gitversion/jobs/356052758/config
Hey again everyone, more detail on my problem from a few days ago:
mode: Mainline increment: Patch branches: develop: mode: ContinuousDeployment
When I'm running the above configuration, when I go to generate a version off of
master following a merge of
develop into it, I get the following error:
Mainline development mode doesn't yet support pre-release tags on master
What's weird is that I've never tagged
master with any pre-release tags. Only my develop commits have been the target of pre-release tags... I basically want pre-release behaviour on my
develop branch, but any time I merge to
master, I want it to cause a minor version increment.
Is anyone using GitVersionTask in a GitHub workflow action? I've just tried to set it up and got a rather confusing error message:
GitVersionTask.targets(46,9): error : GitVersionException: Cannot find commit 2108544aed45614f96f35440d4fadfa70773b8e0. Please ensure that the repository is an unshallow clone with
git fetch --unshallow
eek! What do I do?
Hoping somebody can point out what I'm doing wrong here...
I'm using ContinuousDeployment mode for this flow
Commit to master and run gitversion, it outputs 1.1.0-ci.0
Create a release branch (release/v1.1) from master and run gitversion, it outputs v1.1.0-beta.0
Tag the HEAD commit of release/v1.1 and run gitversion on the tag, ERROR
It looks like the branch being examined is a detached Head pointing to commit '88e98c4'. Without a proper branch name GitVersion cannot determine the build version.
But, I joined gitter to ask specifically about monorepos.
I have a large monorepo that I would like to try and tackle if possible. I see some mention of using tag prefixes.
Lets say I have the following
\SuperLibraryThing (NuGet package)
\AnotherLibraryThing (NuGet package)
\SuperApp (ASP.NET Core web app)
I assume I would potentially have a different GitVersion.yml in each of those folders, and I would perhaps set tag-prefix: superlibrarything for the first GitConfig.yml, tag-prefix: anotherlibrarything, for the second, etc