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
Implement ChangeRequestSCMHead2 for SCMHead & SCMRevision #382
Implement ChangeRequestSCMHead2 for SCMHead & SCMRevision #382
Conversation
} | ||
|
||
/** | ||
* The commit hash of the head of the change request branch. |
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 commit hash of the head of the change request branch. | |
* The commit hash of the pull request source branch (source ref) |
|
||
@Override | ||
@NonNull | ||
public SCMHeadOrigin getOrigin() { |
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.
why do we override this just to return the same value as the overridden method?
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.
This is because we need to eventually determine the origin. For now we can copy the default behaviour, but when we add support for branches from forks, we will need to update this method to handle that. I felt like its best keeping it in earlier rather than later. I'm happy to add a comment to the method for when we go back to it
public class BitbucketSCMRevision extends SCMRevision { | ||
|
||
private static final long serialVersionUID = 1L; | ||
private final String hash; |
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.
private final String hash; | |
private final String commitHash; |
- change name of getter
just to be explicit and avoid confusing ourselves. Up to you though
src/main/java/com/atlassian/bitbucket/jenkins/internal/scm/MinimalPullRequest.java
Show resolved
Hide resolved
return Collections.singletonMap(new GitBranchSCMHead(fromRef.getDisplayId()), | ||
new GitBranchSCMRevision(new GitBranchSCMHead(fromRef.getDisplayId()), fromRef.getLatestCommit())); | ||
BitbucketPullRequestSCMHead prScmHead = new BitbucketPullRequestSCMHead(getPayload().getPullRequest()); | ||
return Collections.singletonMap(prScmHead, |
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.
This is totally fine, but we also have Map.of(k,v)
which may be nicer? Up to you.
I guess this would fix [JENKINS-66581] Implement ChangeRequestSCMHead2 for pull requests. |
ChangeRequestSCMRevision<?> that = (ChangeRequestSCMRevision<?>) o; | ||
if (!equivalent(that)) { | ||
return false; | ||
} |
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.
This looks like infinite recursion to me. I don't see the purpose of the cast either, as the type of o
is already ChangeRequestSCMRevision<?>
.
public class BitbucketPullRequestSCMHead extends BitbucketSCMHead implements ChangeRequestSCMHead2 { | ||
|
||
public static final int PR_NAME_BRANCH_MAX_LENGTH = 20; | ||
public static final String PR_NAME_TEMPLATE = "pr%s--%s--%s"; |
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.
What does this name affect in Jenkins?
In a multibranch pipeline project, if Jenkins has generated a branch job for a pull request, and I change the target branch of the PR in Bitbucket Server, then will Jenkins generate a separate job for the new name, or will it continue the preexisting job as the pull request ID still matches?
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 name affects the title of the job in the Pull Requests tab. It's a good question of whether we should generate a seperate job for a name change. Any thoughts @dkjellin @jaguilar-atl?
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'd like to keep the same Jenkins job for the same pull request, no matter how it is edited. The URL of the Jenkins job should also stay the same.
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.
then will Jenkins generate a separate job for the new name, or will it continue the preexisting job as the pull request ID still matches?
Good point. I haven't tested it myself, but yes, I think it will generate a separate job as it uses the name as the unique identifier. I do agree that the Job should stay the same for a PR regardless of the target branch.
With that said, we should probably just use the PR id here to ensure that's the case @atl-dyon.
Thanks for raising this @KalleOlaviNiemitalo !
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 Bitbucket Branch Source plugin formats names like PR-1234 and this is useful for including/excluding by wildcard in a multibranch project: I can configure the project to include PR-* and release/2.*, and it won't build release/1.* which we no longer support. (For pull requests, including by type might be more reliable than PR-*, but I don't know if that is available from any plugin.)
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.
Include/exclude by wildcard is implemented as WildcardSCMHeadFilterTrait in scm-api-plugin, and it compares SCMHead.getName() to the patterns: https://github.com/jenkinsci/scm-api-plugin/blob/64378ab20c60b237483b1fcec104a6d2dc350d11/src/main/java/jenkins/scm/impl/trait/WildcardSCMHeadFilterTrait.java#L91-L103
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.
Bitbucket Branch Source apparently implements the PR-1234 format here: https://github.com/jenkinsci/bitbucket-branch-source-plugin/blob/abb9aa5035c1fb40ed8638728c1245a3562f95b0/src/main/java/com/cloudbees/jenkins/plugins/bitbucket/BitbucketSCMSource.java#L682-L706
and in some constructors of PullRequestSCMHead, but those are all deprecated, presumably because they were not able to support multiple build strategies (source branch or merge) for the same pull request.
On the naming of pull requests: Branch API 2.1105.v472604208c55 was just released with a fix for [JENKINS-55348] Display Pull Request Name instead of ID in the UI. It is now able to read the title of the pull request from an |
…' into dg/implement-scmHead-scmRevision
eddb5b5
into
feature/JENKINS-66581-PR-support
Changes the git SCMHead and SCMRevision to use ChangeRequestSCMHead2.
Submitter checklist