Skip to content
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

Merged

Conversation

atl-dyon
Copy link
Collaborator

Changes the git SCMHead and SCMRevision to use ChangeRequestSCMHead2.

Submitter checklist

  • Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
  • Ensure that the pull request title represents the desired changelog entry
  • Please describe what you did
  • Link to relevant issues in GitHub or Jira
  • Link to relevant pull requests, esp. upstream and downstream changes
  • Ensure you have provided tests - that demonstrates feature works or fixes the issue

@atl-dyon atl-dyon changed the title Dg/implement scm head scm revision Implement ChangeRequestSCMHead2 for SCMHead & SCMRevision May 11, 2023
@atl-dyon atl-dyon added the enhancement New feature or request label May 11, 2023
@atl-dyon atl-dyon marked this pull request as ready for review May 11, 2023 00:30
}

/**
* The commit hash of the head of the change request branch.

Choose a reason for hiding this comment

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

Suggested change
* 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() {

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?

Copy link
Collaborator Author

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;

Choose a reason for hiding this comment

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

Suggested change
private final String hash;
private final String commitHash;
  • change name of getter

just to be explicit and avoid confusing ourselves. Up to you though

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,

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.

@KalleOlaviNiemitalo
Copy link

Comment on lines 35 to 38
ChangeRequestSCMRevision<?> that = (ChangeRequestSCMRevision<?>) o;
if (!equivalent(that)) {
return false;
}

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";

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?

Copy link
Collaborator Author

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?

Copy link

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.

Copy link
Collaborator

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 !

Copy link

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.)

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

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.

@KalleOlaviNiemitalo
Copy link

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 ObjectMetadataAction and display that as the job name. This already works with the Bitbucket Branch Source plugin. The Bitbucket Server Integration plugin however doesn't seem to add an ObjectMetadataAction yet. It is not necessary to implement that as part of this PR but please keep it in mind for the future.

@jaguilar-atl jaguilar-atl merged commit eddb5b5 into feature/JENKINS-66581-PR-support Jun 13, 2023
12 checks passed
@jaguilar-atl jaguilar-atl deleted the dg/implement-scmHead-scmRevision branch June 13, 2023 10:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
4 participants