Skip to content

Conversation

@bitwiseman
Copy link
Contributor

@bitwiseman bitwiseman commented May 18, 2019

We tried using strict merge commit handling to prevent cloning on master.
This resulted in some edge cases for some users where PRs would simply not build
and there was not viable workaround.

Change:

  • Merge hash has been changed to best effort. If it is missing or inconsistent,
    Jenkins will gracefully revert to cloning on master.
  • Most validity checking for merge hash has been moved to create time.
  • Plugin tries harder than before to create a valid merge hash revision.

https://issues.jenkins-ci.org/browse/JENKINS-57371

@bitwiseman bitwiseman force-pushed the JENKINS-57371 branch 7 times, most recently from e6d4cda to 0ae74a0 Compare May 22, 2019 00:16
@bitwiseman bitwiseman requested a review from rsandell May 22, 2019 15:15
if (pr.getMergeable() != null) {
mergeHash = Boolean.TRUE.equals(pr.getMergeable()) ? pr.getMergeCommitSha() : PullRequestSCMRevision.NOT_MERGEABLE_HASH;

if (prhead.isMerge()) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Before we would validate the merge later. Now we do a bunch of work to make the merge valid or to ignore it.

if (parents.size() != 2 || !parents.contains(this.getBaseHash()) || !parents.contains(this.getPullHash())) {
throw new AbortException("Invalid merge hash for pull request " + ((PullRequestSCMHead)this.getHead()).getNumber() + " : Head and base commits do match merge commit " + this.toString() );
}
void validateMergeHash() throws AbortException {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

As noted, this validation used to be called in several places and be super strict. Now the checks are done at create time and additional work is done then to make the merge hash valid or to make it null (which case the FileSource will fall back to clone and merge locally).

Copy link
Member

@rsandell rsandell left a comment

Choose a reason for hiding this comment

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

looks good so far

@bitwiseman bitwiseman changed the title JENKINS-57371 - Full enable fallback to clone and merge [JENKINS-57371] - Enable graceful fallback for merge hash May 22, 2019
We tried using strict merge commit handling to prevent cloning on master.
This resulted in some edge cases for some users where PRs would simply not build
and there was not viable workaround.

Change:
* Merge hash has been changed to best effort.  If it is missing or inconsistent,
Jenkins will gracefully revert to cloning on master.
* Most validity checking for merge hash has been moved to create time.
* Plugin tries harder than before to create a valid merge hash revision.
Copy link
Collaborator

@kshultzCB kshultzCB left a comment

Choose a reason for hiding this comment

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

Looks good.

Side note, I really like the practice of putting comments into your own PRs explaining what's going on. That is really helpful.

@rsandell
Copy link
Member

Side note, I really like the practice of putting comments into your own PRs explaining what's going on. That is really helpful.

Though most of the time I'm wondering why those comments aren't in the code instead.

@bitwiseman bitwiseman merged commit ea479ae into jenkinsci:master May 23, 2019
@bitwiseman bitwiseman deleted the JENKINS-57371 branch May 23, 2019 18:32
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.

4 participants