[Bug] GitVersion unable to work with remote reference and needs local copy of branches

[arpit9mittal]

Currently the GitVersion to support gitflow requires all the branches to be local in-order to get the correct version. This is not an issue when working on individual dev machines, but when you start using them with centralized build tool like Jenkins etc., downloading all the branches into the container becomes a challenge. As it takes lots of disk space and time (depends on how clean the graph is, i.e. people remove unwanted feature branches with discipline). My company build pipeline do not download all the branches and thus versioning breaks.

Expected Behavior

Let refer to a simple example, where master is tagged at 1.1.0

• a commit on develop branch and build creates a version 1.2.0-alpha.#
• a feature branch "version_test" created from develop, with commit and build should give version 1.2.0-version-test.1+##

Actual Behavior

A feature branch "version_test" created from develop, with commit and build gives version 1.1.0-version-test.1+## The reason is the develop branch is not downloaded in to the build pipeline container, as it only gets master and "version_test" branch.

Possible Fix

If GitVersion is able to get the information from the remote repository instead dependent on branches available it would resolve the issue.

Steps to Reproduce

1. create a simple repo with spring boot samples
2. tag the master with 1.1.0
3. create develop and make a commit , creating the version "Major": 1, "Minor": 2, "Patch": 0,
4. create a feature branch "feature/version_test" and make a commit.
5. gitversion will show a version "Major": 1, "Minor": 2, "Patch": 0,
6. delete the develop branch from local
7. gitversion will show a version "Major": 1, "Minor": 1, "Patch": 0,

Context

Since due to limited space for the build container, the build pipeline cannot download all the branches. This is limiting us to make the use of this wonderful tool. Only teams in our company that uses Mainline branch strategy are able to use this tool while projects that uses gitflow have to continue manually control their versions.

Your Environment

All environments

• Version Used: 5.8.1
• Operating System and version (Windows 10, Ubuntu 18.04): all
• Link to your project: cannot due to confidentiality
• Link to your CI build (if appropriate): NA

[asbjornu]

If GitVersion is able to get the information from the remote repository instead dependent on branches available it would resolve the issue.

Isn't this what dynamic repositories are for?

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs.

[trreeves]

So another way of phrasing this issue could be:

DynamicRespository feature requires large disk space for big repositories, which prevents usage in constrained build environments such as containers where resource limits are enforced.

And an idea for solving this could be for the Dynamic Repository feature to take advantage of some more recent native Git features added to make it more manageable to work with large repositories. i.e. Partial Clones and Sparse Checkout and Sparse Indexes.

Some references:

• https://github.blog/2021-11-10-make-your-monorepo-feel-small-with-gits-sparse-index/
• https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/

The initial clone would be fast, and take up minimal disk space, providing GitVersion didn't trigger the on-demand downloading of file contents as part of the version calculation.

I'm not particularly familar with the lower-level implementation detail of GitVersion, but my assumption is that GitVersion would only need the commit history to calculate the version; not the tree history or the file contents?

So using partial clones and sparse-checkout, could allow GitVersion to make a light-weight, small-footprint clone of a repo:

# Clone without downloading file contents or directories
git clone --filter=tree:0 --no-checkout https://github.com/GitTools/GitVersion.git

# initialise sparse-checkout and sparse-index, so only contents in the root folder are fetched and placed in the index and working directory
git sparse-checkout init --cone --sparse-index
git checkout main

At the moment, just running GitVersion now on this partial-clone fails. It also fails with --filter-blob:none for the clone command as well, for a different error. But, is this a viable approach that could be made to work? I don't know the detail of how GitVersion interrogates the commit history, and whether that's compatible with this approach (could it not avoid triggering the on-demand download of file contents?)

Another constraint on this approach is that the --filter parameter isn't necessarily supported yet on all servers. Azure DevOps for example doesn't support it (ironically as it seems it was the Git team in DevOps that developed it, but they have their reasons). Github does support it. Not sure what other servers do/don't. But it could be made opt-in via a parameter for now.

[trreeves]

I've also come up against problems with Dynamic Repository where the clone is being made to my users temp folder, and the repo has some very deep folders and file names, so I encouter path-too-long errors during the clone. Again, GitVersion shouldn't technically need to hydrate the files into the work tree to calculate the version from the commit history, which brings with it multiple consquences.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs.