Skip to content

Add check for incorrect rebase by checking for duplicate commits and …#221

Open
xjusko wants to merge 1 commit intowildfly:mainfrom
xjusko:detect-incorrect-rebase
Open

Add check for incorrect rebase by checking for duplicate commits and …#221
xjusko wants to merge 1 commit intowildfly:mainfrom
xjusko:detect-incorrect-rebase

Conversation

@xjusko
Copy link
Collaborator

@xjusko xjusko commented Apr 11, 2025

…skip PR rules if any appear.
resolves #207

@xjusko xjusko force-pushed the detect-incorrect-rebase branch 2 times, most recently from 3ccbf2d to ceb0992 Compare April 30, 2025 07:45
@xjusko xjusko requested a review from mskacelik April 30, 2025 07:47
.toList());
}

public boolean hasDuplicateCommitInBase(GHPullRequest pullRequest, GHRepository repository)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it necessary to have the hasDuplicateCommitInBase defined in the GithubProcessor, rather than having a private method in PullRequestRuleProcessor?

Afaik, the method does not use any of the class's states except for LOG.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tbh, I placed it there, since the PullRequestRuleProcessor already uses method which are specific for this class and are in the GithubProcessor.
However, I can change it if you think it is better. I have no real preference, since I can see that there are some processors that also have helper methods inside its own class, and other which have those helper methods in GithubProcessor

Copy link
Collaborator

@mskacelik mskacelik Jun 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am thinking of three possible solutions:

1) Remove the method and use private methods for each processor.

Cons:

  • It would be impossible to test, especially if some private methods perform more complex tasks.
  • It would also bloat the individual Processor classes.

2) Make it a static method.

Pros:

  • Since it's stateless, it would make more sense to have it as a static method.
  • Decomposition.

Cons:

3.) Leave it as it is.

  • ...

Copy link
Collaborator Author

@xjusko xjusko Jun 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would leave it as it is. Or at least change it in another PR if it is needed.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok

Comment on lines +113 to +115
Set<GHCommit> fakeRepoCommitSet = new HashSet<>();
fakeRepoCommitSet.add(commit1);
fakeRepoCommitSet.add(commit2);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Set<GHCommit> fakeRepoCommitSet = new HashSet<>();
fakeRepoCommitSet.add(commit1);
fakeRepoCommitSet.add(commit2);
Set<GHCommit> fakeRepoCommitSet = Set.of(commit1, commit2);

Comment on lines +136 to +141
.then(mocks -> {
verify(mocks.pullRequest(pullRequestJson.id())).getBase();
verify(mocks.repository(TestConstants.TEST_REPO)).queryCommits();
verify(mocks.pullRequest(pullRequestJson.id()), times(3)).listCommits();
});
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, what about some checks that it did not do any rule hitting (aka the method ended before the rule hitting and other stuff...). Is it possible to check, for example, if there is no "/cc" comment (or reviewers), while the config file (with rules) is present?

Because I don't see a check that checks the "skip" part in this code, if that makes sense.

@xjusko xjusko force-pushed the detect-incorrect-rebase branch from ceb0992 to bdd795d Compare June 17, 2025 14:29
Comment on lines +139 to +140
verify(mocks.pullRequest(pullRequestJson.id()), never()).addLabels(any(String[].class));
verify(mocks.pullRequest(pullRequestJson.id()), never()).requestReviewers(anyList());
Copy link
Collaborator

@mskacelik mskacelik Jun 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
verify(mocks.pullRequest(pullRequestJson.id()), never()).addLabels(any(String[].class));
verify(mocks.pullRequest(pullRequestJson.id()), never()).requestReviewers(anyList());
verify(mocks.pullRequest(pullRequestJson.id()), never()).addLabels(any());
verify(mocks.pullRequest(pullRequestJson.id()), never()).requestReviewers(any());

any() also includes null, so I think it's better to have it for all cases when using never()* since it widens the set of rejected conditions.

*there are exceptions, for example:

verify(code()).foo("expected-value"); // one expected value
verify(code(),never()).foo(any());  // all the other values are not allowed – this does not work because any() also accepts "expected-value"

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mskacelik, thanks for catching this
I had to change a bit differently, since addLabels is an overloaded method, I had to use nullable(String[].class}

…skip PR rules check(mentions, reviewers) if any appears.
@xjusko xjusko force-pushed the detect-incorrect-rebase branch from bdd795d to 8313e9f Compare July 6, 2025 19:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Prevent assigning a large number of reviewers when a pull request is opened after an incorrect rebase.

2 participants