Matching of the GitSCM url to the Bitbucket Payload repository URL logic broken ?

[cyberguard]

in BitBucketPPRPullRequestAction The SCM URL value for the commit repository is taken from the Bitbucket JSON payload from the payload.getRepository().getLinks().getHtml().getHref()

Bitbucket always set that to a value of https://bitbucket.org/XXXX/YYYY . Note that the URL present in the JSON

• never has the userid@ prefixed.
• It also does not have the .git suffix

However in the Git SCM config, for the Repository URL to be valid when doing the git fetch I have to prefix with my username i.e. https://ZZZZ@bitbucket.org/XXXX/YYYY.git

When processing the commit, GitSCM tries to compare the URL present in the BitBucket payload to the URL of the Git SCM.

Because the two are never equal we always end up with the error/warning of

• skipping resolution of commit eef18d94302f5a3945796e77ee8ec46a69fd1ddf, since it originates from another repository

which cause the GitSCM plugin to randomly pick any commit that it did not compile yet. (i.e. Multiple candidate revisions)

Am I missing something or is the logic broken ?

Seems to me we would need the ability to configure an GitURL equivalence map between what is in the BitBucket Webhook JSON Payload & the Git SCM Url.

I quickly tested by doing modifying BitBucketPPRPullRequestAction to swap the HTTPS url for the SCM URL and it correct the behavior.

GIT_COMMIT is set to the exact commit of the Bitbucket.Json.pullrequest.source.comit.hash value and the GitSCM plugin is no longuer complaining about it originating from another PR.

Therefore the exact commit of the PR is build instead of a random one.

  public BitBucketPPRPullRequestAction(@Nonnull BitBucketPPRPayload payload) {
    this.payload = payload;

    // TODO Why??

    String href = payload.getRepository().getLinks().getHtml().getHref();
    if ( href.equals( "https://bitbucket.org/XXX/YYY" ) ){
      href = "https://ZZZZ@bitbucket.org/XXXX/YYYY.git";
    }
    scmUrls.add(href);
  }

Am I missing something or is this a known limitation / bug of the current code base ?

[YungTosti]

This is a huge problem, I also have this problem and it breaks the entire purpose of this plugin....

[cdelmonte-zg]

Hello @cyberguard

would be okay for you to open a pull request with your solution? If all works properly, I would add it to the next release

Thanks Christian

[cyberguard]

Hi @cdelmonte-zg,

I don't mind opening a PR, however please note that currently it works only for when the Git SCM is configured with https (i.e. https://xxxx@bitbucket.org/yyy/zzz.git ) and not with SCM setup (i.e. git@bitbucket.org:xxx/yyy.git)

I always plan on finding a free sec to figure it out since I prefer ssh but did not get around to it.

I also did not yet also had the time to set up Unit test for this.

Finally, while it works, I wanted to see and figure out if there was a way to have it defined at a single place instead of in each trigger. Which means the setup screen looks like:

I just wanted to point out that while it works, it may not be polished enough to be accepted into the main code line.

Plese let me know what you think.

[karniemi]

Hi,

would this also help cases where bitbucket is running behind a reverse proxy in a different context-path, e.g. "https://mysite.com/bitbucket" (instead of running directly at root: "https://mybitbucket.com/")?

Because currently, the plugin directs the status notifications like this: ""POST /rest/build-status/1.0/commits/a1ac43d397f65e1565d29eb45bd4fbb36412cada HTTP/1.1[\r][\n]" ... so they won't reach bitbucket, because the reverseproxy has no idea about such path (ie. starting with "rest/" - instead of the correct "bitbucket/rest/"), and returns "404 Not found".

The setup is instructed here, by Atlassian: "https://confluence.atlassian.com/bitbucketserver/secure-bitbucket-behind-nginx-using-ssl-776640112.html". I had a look at the webhook, and it seemed that -sadly- bitbucket does not deliver the base-url/context-path in the webhook.

[bxliam]

I think we need to add support for SSH/HTTP matching to?

{ "object_kind": "note", "event_type": "note", "user": { "id": 1, "name": "[REDACTED]", "username": "[REDACTED]", "avatar_url": "[REDACTED]", "email": "[REDACTED]" }, "project_id": 1, "project": { "id": 1, "name": "[REDACTED]", "description": "", "web_url": "https://gitlab.com/my/path/to/project", "avatar_url": null, "git_ssh_url": "git@gitlab.com:my/path/to/project.git", "git_http_url": "https://gitlab.com/my/path/to/project.git", "namespace": "my", "visibility_level": 0, "path_with_namespace": "my/path/to/project", "default_branch": "main", "ci_config_path": "", "url": "git@gitlab.com:my/path/to/project.git", "ssh_url": "git@gitlab.com:my/path/to/project.git", "http_url": "https://gitlab.com//my/path/to/project.git" },

You can see here the the URL gitlab webhook sends is ALWAYS ssh url, even if you only use HTTPS (which we do) this causes this error to occur "skipping resolution of commit" even though it is same repository but just SSH vs HTTPS in the URL field

[julioc-p]

Hi @cyberguard. Thanks for reporting. This issue is supposed to be fixed with PR #341. Feel free to try it out and report if it does not solve your problem