Fix issue 3074 by ignoring commits in several places #3173
Conversation
|
it seems to me the Mac tests have some instability since there is an error because of a corupt git repository or something. |
|
this one seems to fail in https://github.com/GitTools/GitVersion/runs/8004381283?check_suite_focus=true on macos latest but nowhere else. Is this flaky? Would a restart (don't know if I could do that) help? |
|
Ok. the test CacheKeyForWorktree was breaking in 3 consecutive runs on macos latest and is green anywhere else. Did anyone already look into that? |
|
I noticed that as well, the macos with netcoreapp3.1 tests. For now re-running the failed job helps, but we will sunset .netcoreapp3.1 soon anyway, so we might disable the tests for this specific configuration |
Thx for the info. Do you think I should remove the Retry-Attribute that I just added to the test? Since the code itself is also doing a retry I figured it would do no real harm to anyone. |
|
@rominator1983 please rebase your PR on main, I have disabled the tests for macos netcoreapp3.1 |
|
please rebase you PR on main, I have disabled the tests for macos netcoreapp3.1 |
rominator1983
force-pushed
the
fix/IgnoreAllCommits_Issue3074
branch
from
222c92b to
f28ac82
Compare
|
Thanks @arturcic ! |
|
When do you think can this be made available? |
|
I'm a bit uneasy about all the removed and modified tests. I would also like @ibvhefe to take this PR for a spin to see if it solves their issue. |
|
Sorry. I need this for a private project and I barely find the time. Add this to [Test]
public void CommitsWithSemverCommentsAreIgnored()
{
using var fixture = new EmptyRepositoryFixture();
fixture.Repository.MakeATaggedCommit("1.0.0");
fixture.Repository.CreateBranch("feature/foo");
fixture.Checkout("feature/foo");
fixture.Repository.MakeACommit("2");
fixture.MakeACommit("3 +semver:minor");
fixture.Checkout(MainBranch);
fixture.Repository.MergeNoFF("feature/foo");
var commit = fixture.Repository.MakeACommit("4 +semver:major");
var config = new ConfigurationBuilder()
.Add(new Config
{
VersioningMode = GitVersion.VersionCalculation.VersioningMode.Mainline,
Ignore = new IgnoreConfig
{
Before = DateTime.Now.AddMinutes(1)
}
}).Build();
fixture.AssertFullSemver("1.0.0", config);
} |
|
@ibvhefe thanks for the provided test. Does it fail on @rominator1983's |
|
On both
Holen Sie sich Outlook für Android<https://aka.ms/AAb9ysg>
…________________________________
From: Asbjørn Ulsberg ***@***.***>
Sent: Thursday, September 29, 2022 1:23:55 PM
To: GitTools/GitVersion ***@***.***>
Cc: ibvhefe ***@***.***>; Mention ***@***.***>
Subject: Re: [GitTools/GitVersion] Fix issue 3074 by ignoring commits in several places (PR #3173)
@ibvhefe<https://github.com/ibvhefe> thanks for the provided test. Does it fail on @rominator1983<https://github.com/rominator1983>'s fix/IgnoreAllCommits_Issue3074 branch<https://github.com/rominator1983/GitVersion/tree/fix/IgnoreAllCommits_Issue3074> or on GitTools:main?
—
Reply to this email directly, view it on GitHub<#3173 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADSIBBJYZG43JBJW63RPYQDWAV34XANCNFSM57QUBR5A>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Think I'm gonna check it out then. |
arturcic
force-pushed
the
main
branch
2 times, most recently
from
be69f4f to
1826e18
Compare
arturcic
force-pushed
the
main
branch
2 times, most recently
from
9801764 to
b7a7608
Compare
|
@rominator1983 please rebase your PR on top of the current state of the |
|
Ok guys. I'm gonna rage quit this. My original code is not applicable in any way after you let it sit there silently for half a year. And since there were a lot of changes upstream I don't exactly know if the original problem does still occur anyways. So... |
Description
Previously commits where only ignored (by SHA or date) in one place when getting the base versions.
The info if a commit is ignored or not is now produced right when getting the commit log and can then be used where needed.
This info is now also evaluated when getting the increment of a single commit out of it's commit message.
Up to now there could have been commits leading to a version raise (through their commit message) even though they were ignored by date or explicitly by SHA. This has been ammended.
Related Issue
Fixes #3074.
Motivation and Context
Bit-bucket in its default configuration adds the latest 20 commit message of a source branch to the commit of a PR merge. This multiplies the occurrences of "+semver:major" commit messages in the log which can't possibly be undone if you just see this some weeks later and there are several people on the project.
When doing PRs to merge from develop to a feature branch this can result in unwanted version raises.
How Has This Been Tested?
I implemented/adapted some integration tests that were red to begin with and got green when I implemented my changes. When deactivating my changes several tests got red too.
Where I did refactorings I checked if their were tests for the previous code by uncommenting parts of it (See changes in BaseVersionCalculator).
Screenshots (if appropriate):
Checklist:
... My change requires a change to the documentation. (The documentation already stated that you could ignore single commits by SHA which was not true for all cases. So the code now conforms better to the documented behavior)
... I have updated the documentation accordingly. (No.)