Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Feature: Support ignoring (filtering) paths in git tree #4420
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
base: main
Are you sure you want to change the base?
Feature: Support ignoring (filtering) paths in git tree #4420
Changes from all commits
e45f63c
9d9c5dd
ad8bc2f
354790e
1152953
a3003ef
b3a10eb
0e5359e
6c0e49f
a397bf5
e84e12b
001b673
ec630ba
dd643e2
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not the business of the IncrementStrategyFinder to filter the commits by the specified ignore settings. At this point only commits who are part of the calculation should be passed into the method. That means the exclusion of the commits have happend much earlier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see.
Let me just clarify my concern, that if filtering based on paths is done eagerly, this will cause performance issues, especially for large commit history, due to the costly patch calculation (from what I saw on my machine, every patch calc takes as long as ~100ms).
I believe that current implementation defers the filtering well till it is required.
This issue applies generally whenever filtering needs to be done.
With that in mind, my suggestion is not to filter earlier, but rather later.
Would that make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regardless of the point if it is evaluated earlier in the execution or not: Isn't it necessary in almost every case to decide whether a commit (beginning from the last tagged commit) should be ignored or not? For instance the variable
CommitsSinceTag
andCommitsSinceVersionSource
can be calculated only if you evaluate it for every commit.GitVersion/src/GitVersion.Core/VersionCalculation/VersionCalculators/VersionCalculatorBase.cs
Lines 17 to 26 in dd9434b
Of course we need to ensure that for each commit the evaluation happens only one time and onyl if it is really necessary. Would it be an idea to extend the
ICommit
interface by providing a property with the following structure?This property can be implemented with delayed loading and the result can be cached as well. At the moment we have some problems with caching (please keep this in mind):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have tought about it and it is indeed very bad from the performance perspective, if in a potential scenario the
CommitsSinceTag
andCommitsSinceVersionSource
variable will be calculated but the user don't use it.This applies for
ManualDeployment
andContinuousDeployment
mode if you are only interested in e.g. theSemVer
variable.GitVersion/src/GitVersion.Core/VersionCalculation/VersionCalculators/ManualDeploymentVersionCalculator.cs
Lines 23 to 26 in dd9434b
and
GitVersion/src/GitVersion.Core/VersionCalculation/VersionCalculators/ContinuousDeploymentVersionCalculator.cs
Lines 23 to 31 in dd9434b
Edit: I think the performance problem we have in this scenario needs to be addressed maybe later by changing the business logic (out of scope of this issue). For instance we could introduce a new configuration to skip the calculation of the
CommitsSinceTag
andCommitsSinceVersionSource
variable.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry if I need to tell you this: Also this code change needs to be reverted. The filtering has been done already in:
It makes aboslute no sense to check it again.
Just a side note: Generally I think the ignore implementation in this class is only a safe guard implementation... Normally I would expect that only base versions from the
versionStrategy.GetBaseVersions(..)
method are returned who are part of the execution (the ignore business logic has been applied and not filtered).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea here is similar to the one before - defer the filtering of commits. Without these changes, the filtering would have happened on every single commit which is considered as a base version for the calculation.
On the other hand, since it handles the base versions only, maybe many of commits won't be flowing through this filtering, therefore performance is less of an issue here IDK.
Regarding your comment about it being a safe guard - my understanding is that this part is responsible for filtering the base versions, which are only partially filtered by the commit SHA alone in
versionStrategy.GetBaseVersions
implementations.Let me know what you think we should do here, and I'll adjust the logic accordingly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes the code absolutely unmaintainable and error prone if we have a ignore configuration with different filtering methods, which are executed on different code level. I see your motivation... But we need to find a way where both aspects (performance/delayed loading/caching and BL where it is expected and intenionally) are considered. Does this make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please revert the logic to exclude the FallbackVersionStrategy.The FallackVersionStrategy class is like every other version strategy class and should not handled explicit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason for this, is the deferral of filtering to all other strategies other than
FallbackVersionStrategy
, simply because I wasn't sure how to handle the case whereatLeastOneBaseVersionReturned=false
. Ideally, if deferring the filtering, this condition won't be here and theIncludeVersion
will not be invoked here.I'll change it after resolving previous comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You see, this is not a good design (and makes it hard to understand) if you apply a implicit knowledge about the fact that the base version fo
FallbackVersionStrategy
is already evaluated. You are skipping it because of performance reason.. We need to find a design on an abstraction level e.g. ICommit interface where we ensure this aspect. We need to have transparent calls in the business logic without implicit assumptions.Edit: Anyway, an idea would be to remove the filtering in
NextVersionCalculator
generally and ensure that theIVersionStrategy
implementation classes only returning evaluated base versions.