-
Notifications
You must be signed in to change notification settings - Fork 639
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] GitVersion unable to work with remote reference and needs local copy of branches #2921
Comments
Isn't this what dynamic repositories are for? |
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. |
So another way of phrasing this issue could be:
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:
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 Another constraint on this approach is that the |
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. |
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. |
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
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
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
The text was updated successfully, but these errors were encountered: