Jenkins will not match repository if pulling from HTTP

[pvginkel]

Issue

Context

• Gitlab plugin version: 1.4.5
• Gitlab version: 8.14.0
• Jenkins version: 2.32.1
• Job type: Freestyle

Logs & Traces

skipping resolution of commit remotes/origin/release, since it originates from another repository

Problem description

The GitLab plugin will use the repository.url field to identify the repository a (commit/merge request/etc) push comes from. This however is the SSH url. When the Jenkins clone is pulled from HTTPS, it will not correctly match the push against the clone.

A work around is to change the field to repository.git_http_url, but this would break existing installations. See https://github.com/pvginkel/gitlab-plugin/commit/f1bd7748d158de7210f76f767e0a7ce7b639cb4d for these changes. Probably this should become a setting since it seems that RevisionParameterAction can only accept a single URL, so the decision of what URL to pass needs to be made in the GitLab plugin. Another option would be do something in GitLab but, alas, https://github.com/gitlabhq/gitlabhq/blob/9ad0d879fb99685f5b41994911983ab7d05ace31/app/models/project_wiki.rb#L35 implies that this is not configurable.

[AnatolyRugalev]

I have exactly same problem with Pipeline job. Any plans on this issue?

[mschuckmann]

I think I have this problem, I've tried using the ssh URL and http URL (our server is not setup with https) when specifying the git remote and I always get the message:

skipping resolution of commit 01a8d0564a76c6d557d2f6dfeb34caf477f30a75, since it originates from another repository

When it attempts to merge and build for a merge request. Any suggestions on what I should do?

[omehegan]

@mschuckmann cloning with the ssh URL should always work. The error you are getting technically comes from the git plugin, not the GitLab plugin. You might want to look at that plugin's documentation for more debugging help.

[drewwells]

Query for this issue on gitlab issue list: https://issues.jenkins-ci.org/browse/JENKINS-45246?filter=-4&jql=text%20~%20%22originates%20from%20another%20repository%22%20order%20by%20created%20DESC

[pvginkel]

I don't agree this is an issue in the Git plugin. I think I understand the reasoning, but at the end of the day, the GitLab plugin is passing the wrong data to the Git plugin. I don't have a good answer as how to solve this (maybe the Git plugin could be extended to receive multiple URIish instances).

Anyway, until this issue has been solved, the only work around I know is to use a modified version of the GitLab plugin. I've synced with the latest release and created a release of the GitLab plugin at https://github.com/pvginkel/gitlab-plugin/releases/tag/gitlab-plugin-1.5.2 for anyone that needs it.

[omehegan]

@pvginkel I guess I don't understand why you don't just use the SSH URL for the clone.

[pvginkel]

Because Git over SSH is disabled on my gitlab instance.

On Mon, Jan 15, 2018, 11:48 Owen Mehegan [email protected] wrote:

@pvginkel https://github.com/pvginkel I guess I don't understand why you don't just use the SSH URL for the clone.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/jenkinsci/gitlab-plugin/issues/477#issuecomment-357647517, or mute the thread https://github.com/notifications/unsubscribe-auth/AAymJtVnJmU0eVN2upTmZ4p5CGu0Ldddks5tKyzygaJpZM4LcgMi .

[omehegan]

@pvginkel I see, I misread the history. My comment about the git plugin was directed only at @mschuckmann who reported that he got the same error with both SSH and HTTP clones. I had already marked this as a possible plugin bug. We just need to come up with a more compatible fix.

[pvginkel]

Yeah I get that. When going through the source code it was clear that the real problem is that the library being used doesn't allow for multiple URLs. My guess is that the only option without changing that is going to be a setting, so that the correct URL can be selected from the gitlab request. That however is going to be messy since probably people are not going to understand the purpose of the setting.

[omehegan]

@pvginkel we can probably make it an advanced global config option for folks like you who have SSH disabled. The option will then use the HTTP URLs instead.

[Hartorn]

@omehegan Any news on that ? I seem to have the same problem. SSH is not activated, so I cannot switch to ssh URL.

[Kollerb04]

Same issue here.

[dmclean62]

I think I might be having this same problem, and also cannot use SSH.

Here's the console output of my build:

Triggered by GitLab Merge Request #1: OED_DSB/PROMPT-49 => master Checking out git https://redacted/OED_DSB/prompt.git into /local/jenkins/workspace/DSB/PROMPT Change Integration@script to read Jenkinsfile.ci using credential adb48264-2c47-4538-96ee-238ed1de337b

git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository git config remote.origin.url https://redacted/OED_DSB/prompt.git # timeout=10 Fetching upstream changes from https://redacted/OED_DSB/prompt.git git --version # timeout=10 using GIT_ASKPASS to set credentials git fetch --tags --progress https://redacted/OED_DSB/prompt.git refs/changes/:refs/changes/ # timeout=10 skipping resolution of commit 406c22dda14cd411d04bb77bec329a452167841c, since it originates from another repository git rev-parse refs/remotes/origin/PROMPT-49^{commit} # timeout=10 git rev-parse refs/remotes/origin/origin/PROMPT-49^{commit} # timeout=10 git rev-parse origin/PROMPT-49^{commit} # timeout=10 ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job. ERROR: Maximum checkout retry attempts reached, aborting Finished: FAILURE

[binakot]

Didn't find another solution and switch to SSH for all my builds & pipelines 🤕

[slide]

Does disabling the SSH protocol make the getUrl return the http(s) url? https://docs.gitlab.com/ee/user/admin_area/settings/visibility_and_access_controls.html#enabled-git-access-protocols

[BreakBB]

@MaximeMazet Can you share any insight on this? It seems many users (just like me) are having problems with the plugin choosing the SSH URL over the HTTP URL.

[builder-main]

I think I might be having this same problem, and also cannot use SSH.

Here's the console output of my build:

Triggered by GitLab Merge Request #1: OED_DSB/PROMPT-49 => master Checking out git https://redacted/OED_DSB/prompt.git into /local/jenkins/workspace/DSB/PROMPT Change Integration@script to read Jenkinsfile.ci using credential adb48264-2c47-4538-96ee-238ed1de337b

git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository git config remote.origin.url https://redacted/OED_DSB/prompt.git # timeout=10 Fetching upstream changes from https://redacted/OED_DSB/prompt.git git --version # timeout=10 using GIT_ASKPASS to set credentials git fetch --tags --progress https://redacted/OED_DSB/prompt.git refs/changes/:refs/changes/ # timeout=10 skipping resolution of commit 406c22dda14cd411d04bb77bec329a452167841c, since it originates from another repository git rev-parse refs/remotes/origin/PROMPT-49^{commit} # timeout=10 git rev-parse refs/remotes/origin/origin/PROMPT-49^{commit} # timeout=10 git rev-parse origin/PROMPT-49^{commit} # timeout=10 ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job. ERROR: Maximum checkout retry attempts reached, aborting Finished: FAILURE

I'm having the exact same log when testing Merge Request Trigger with Gitlab-Jenkins integration. However the issue does not appear when testing the Push Trigger. Although I still get the line about the HEAD commit being skipped.

I believe the issue might come in if the merge request only has one commit (as it is skipped) ?

[builder-main]

I additionally found out that when going to the Merge Request triggered repo the test was done with an old merge request that had no matching branch anymore. Might be the issue some people face ?

[bjmi]

Switching from HTTPS to SSH URL fixes this for me too. RevisionParameterAction.canOriginateFrom(Iterable<RemoteConfig> remotes) evaluates to false because GitLab Webhook sends SSH URL and is compared to HTTPS URL in Jenkins.

Webhook payload from GitLab.com to Jenkins:

  "repository": {
    "name": "Modules",
    "url": "[email protected]:..../modules.git",
    "description": "Core modules and components",
    "homepage": "https://gitlab.com/..../modules",
    "git_http_url": "https://gitlab.com/..../modules.git",
    "git_ssh_url": "[email protected]:..../modules.git",
    "visibility_level": 0
  }

https://github.com/jenkinsci/git-plugin/blob/094d7b3a884c6f51037b1a2dde5a7f1cf9f99d54/src/main/java/hudson/plugins/git/GitSCM.java#L1134-L1143

https://github.com/jenkinsci/git-plugin/blob/094d7b3a884c6f51037b1a2dde5a7f1cf9f99d54/src/main/java/hudson/plugins/git/RevisionParameterAction.java#L123-L127

[Woodpeker]

I don't agree this is an issue in the Git plugin. I think I understand the reasoning, but at the end of the day, the GitLab plugin is passing the wrong data to the Git plugin. I don't have a good answer as how to solve this (maybe the Git plugin could be extended to receive multiple URIish instances).

Anyway, until this issue has been solved, the only work around I know is to use a modified version of the GitLab plugin. I've synced with the latest release and created a release of the GitLab plugin at https://github.com/pvginkel/gitlab-plugin/releases/tag/gitlab-plugin-1.5.2 for anyone that needs it.

@pvginkel Hi! I would like to know, why you haven't made a Pull Request? Its realy solved this issue for me, but I am using a newer version of the GiLab plugin.