Support cloning from Bitbucket mirror

[andrey-fomin]

A mirrored Git repository can be configured for fetching references.

The mirror is not used in the following cases:

• If the source branch in a pull request resides in a different repository, the source branch is fetched from the primary repository while the target branch is fetched from the mirror.
• During initial pull request scanning, the mirror isn't used because PullRequestSCMHead doesn't contain the hash needed for the build and SCMRevision is null. This is the current design limitation and can be refactored later.

Cloning from the mirror can only be used with native web-hooks since plugin web-hooks don't provide a mirror identifier.

For branches and tags, the mirror sync event is used. Thus, at cloning time, the mirror is already synchronized. However, in the case of a pull request event, there is no such guarantee. The plugin optimistically assumes that the mirror is synced and the required commit hashes exist in the mirrored repository at cloning time. If the plugin can't find the required hashes, it falls back to the primary repository.

Fixes #592

Co-authors:

• Andrey Fomin https://github.com/andrey-fomin
• Andrei Kouznetchik https://github.com/akouznetchik
• Eugene Mercuriev https://github.com/zamonier

Your checklist for this pull request

• Make sure you are requesting to pull a topic/feature/bugfix branch (right side) and not your master branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or in Jenkins JIRA
• Link to relevant pull requests, esp. upstream and downstream changes
• Did you provide a test-case? That demonstrates feature works or fixes the issue.

[andrey-fomin]

This problem is not caused by this pull request. It's already existing. I believe validation of incoming events is another big task and out of scope of this pull request.

[KalleOlaviNiemitalo]

I was using this API in a private plugin and now I get an error:

java.lang.NoSuchMethodError: 'jenkins.scm.api.SCMRevision com.cloudbees.jenkins.plugins.bitbucket.PullRequestSCMRevision.getPull()'

I suppose rebuilding my plugin might fix that.

[KalleOlaviNiemitalo]

Rolled back to 866.vdea_7dcd3008e for now.

[KalleOlaviNiemitalo]

The private plugin is using this kind of code to get the Git commit ID of the source branch of a pull request:

        SCMRevision revision = SCMRevisionAction.getRevision(scmSource, run);

        // revision might be one of:
        //
        // * in <https://github.com/jenkinsci/bitbucket-branch-source-plugin/>:
        //   - com.cloudbees.jenkins.plugins.bitbucket.BitbucketGitSCMRevision
        //   - com.cloudbees.jenkins.plugins.bitbucket.PullRequestSCMRevision
        // * in <https://github.com/jenkinsci/git-plugin/>:
        //   - jenkins.plugins.git.GitBranchSCMRevision
        //
        // Not all of those are derived from
        // jenkins.plugins.git.AbstractGitSCMSource.SCMRevisionImpl,
        // so we cannot unconditionally cast to that and call getHash().
        if (revision instanceof PullRequestSCMRevision) {
            final PullRequestSCMRevision pullRevision = (PullRequestSCMRevision)revision;
            revision = pullRevision.getPull();
        }

AFAIK, this information is not available from scm-api-plugin and must instead be retrieved via the API of bitbucket-branch-source-plugin. This API is not annotated with any restriction like @NoExternalUse.

[KalleOlaviNiemitalo]

#817 appears intended to fix this binary incompatibility.

[KalleOlaviNiemitalo]

Verified that Bitbucket Branch Source 877.vb_b_d5243f6794, which includes #817, restores binary compatibility with my private plugin.

[jglick]

This is an incompatible change and I think it broke Blue Ocean: jenkinsci/bom#2922 (comment)

Either switch the mirrorId to a (possibly “fluid”) setter, or retain a @Deprecated constructor with the original signature.

[PayBas]

@andrey-fomin I've run into an issue with this.

When configuring a job with a Bitbucket branch source, if you enter the "Owner" the input is case-insensitive.
The "Repository Name" field below "Owner" will be populated correctly, regardless of case.

But then when you actually build a same-origin PR, the prFromTargetRepository will return false, leading to very hard to diagnose issues.

In my case I was severely confused when for 1 specific pipeline my refs were generated as:

"+refs/pull-requests/" + pullId + "/from:refs/remotes/@{remote}/" + headName

instead of the expected:

"+refs/heads/" + branchName + ":refs/remotes/@{remote}/" + branchName

All because I had entered the "Owner" as lower-case (which the Jenkins job config happily accepted), whereas in Bitbucket it is upper-case.

I think this line should be:

boolean prFromTargetRepository = pullRequestRepoOwner.equalsIgnoreCase(scmSourceRepoOwner)
    && pullRequestRepository.equalsIgnoreCase(scmSourceRepository);