-
Notifications
You must be signed in to change notification settings - Fork 654
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
[ISSUE]: GitVersion tool is slow / stalls #4159
Comments
I think it's a logging issue, we need to add more logs for the |
It'd be really nice to know where those three minutes went (maybe it is some out of whack branch or something) |
I'm also having this issue as well, it's very strange. |
I've been able to narrow this down to this method below. When I run this against my repository it runs for ~1.5 minutes as long as I'm on a branch off of GitVersion/src/GitVersion.Core/Core/RepositoryStore.cs Lines 112 to 170 in 719899e
I see the nested loops, I was able to get that number down to 15 seconds but broke some unit tests, so clearly I'm a little out of my depth with what this method needs to do. Hopefully else can it a step further and figure out a good solution! |
I have some proposed changes over at #4208 it appears the culprit is at least partially related to iterating over all the branch commits several different times. |
Hi there. Thank you very much for narrowing down this performance problem. I see your change as an improvement and think it has no downsides. Might it be an idea to do the same change for:
|
There is one detail we need to take in consideration, when the normalization happens we meed to refresh the cache of these collections |
Indeed. Which is another argument for doing normalization as a separate command and step in the build. |
Any sort of (interim) improvement is very welcome because it is getting worse for our builds by the day. |
Same issues here. The Azure step is taking 11 minutes to run, should only take seconds! |
May I ask you: The actual change of the CommitCollection is not effected by the normalization process and can be merged as a short-term hotfix to improve the performance, right? I would say that we merge this change and do the other improvements in an extra ticket. |
I think we better spent the time now to improve the lazy loading/ reset the cached collection, for all git object collections we have than just the one that is in this PR just for the sake of having this merged. So if the author is willing to continue the improving the git object collections loading, then we can help with that, otherwise I would rather improve it myself when I find some time. |
So an interim QFE is really not an option? Even shaving off a few percent would be really highly appreciated as a stopgap until a nicely architected all-encompassing change is done and dusted. |
The thing is we had previously this experience when there was something half-done and the original author of the changes was not willing to continue, and then we had to take it over and redo. So my preference is to get this done first and then merge. I get it that this small change can improve someone's specific case, but let's spend a bit more time and get it done |
I tried 6.0.3 - really impressive! From north of eight minutes down to less than half a minute! Thanks a bunch! |
I'd say thank you to @david-driscoll |
🎉 This issue has been resolved in version 6.0.4 🎉 Your GitReleaseManager bot 📦🚀 |
Prerequisites
GitVersion package
GitVersion.Tool
GitVersion version
6.0.2
Operating system
Linux
What are you seeing?
This is for
on Azure DevOps pipelines (git status only added for testing and because some old issue mentioned that the index might be the culprit).
I am seeing a "pause" in the log - and it always happens for the current PRs branch (pull/2271/merge) End and the Begin of the actual branch I created comparing to develop (GitFlow). Below are two runs, as you can see it seems to wait for 3 minutes for no reason at all.
This also already happened for 6.0.0, I was testing 6.0.2 to see if there would be a difference.
I scrolled all "Took: " and I found one sore thumb:
2024-08-13T07:39:19.2643763Z INFO [24-08-13 7:39:19:26] -< End: Fetching the base versions for version calculation... (Took: 197,524.02ms) >-
However, that would never add up because no other Took: ever exceeded low 100s of ms, most of them were single digit.
What is expected?
Of couse not seeing the pause.
Steps to Reproduce
Not sure if that reproduces outside of our project.
RepositoryFixture Test
No response
Output log or link to your CI build (if appropriate).
No response
The text was updated successfully, but these errors were encountered: