Gitlab-plugin: the gitlab plugin can not get the correct branch

[SilentTiger]

Before submitting an issue to I have first:

• [y] read the documentation on the homepage
• [y] searched for similar already existing issue

(if you have performed all the above, remove the paragraph and continue describing the issue with template below)

Issue

It seems the jenkins can not get the correct branch that I pushed in gitlab.

Context

• Gitlab plugin version: latest
• Gitlab version: 8.6
• Jenkins version: latest

Logs & Traces

Building in workspace /var/lib/jenkins/workspace/juanpiuser

git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
git config remote.origin.url https://gitlab.juanpi.org/oa/JuanpiUser.git # timeout=10
Fetching upstream changes from https://gitlab.juanpi.org/oa/JuanpiUser.git
git --version # timeout=10
git fetch --tags --progress https://gitlab.juanpi.org/oa/JuanpiUser.git +refs/heads/:refs/remotes/origin/
skipping resolution of commit remotes/origin/release, since it originates from another repository
Seen branch in repository origin/master
Seen branch in repository origin/personal/abao/20161020
Seen branch in repository origin/personal/gangtie/dev0705
Seen branch in repository origin/release
Seen 4 remote branches
Checking out Revision cb6169242ccccf007a3fe8bf8d151560313f72c3 (origin/master, origin/release)
git config core.sparsecheckout # timeout=10
git checkout -f cb6169242ccccf007a3fe8bf8d151560313f72c3
git rev-list cb6169242ccccf007a3fe8bf8d151560313f72c3 # timeout=10
git rev-list 793657e1dfc247808ef9761273c892baf18de5a9 # timeout=10

Problem description

I commit a change to master and push it to remote, and then i merged the master to release, and push release to remote, and I see the logs above. It always said "skipping resolution of ....., since it originates from another repositoty", and then I found the value of variable $GIT_BRANCH is 'origin/master'. It should be 'origin/release' in fact.

Can anyone tell me why this? Thanks a lot. I've searched for several days but found nothing useful.

[sgautrin]

The answer comes late but it may still be useful for others. I had to workout the same issue, and for me the problem came from activating a « parametrized build » in order to be able to run the job manually as well. The documentation actually indirectly gives the pointers for why it does not work as expected, through two notices:

• the notification in known issues section about changes made by jenkins
• the note in Git configuration for Freestyle jobs about needing to use EnvInject to set default values since plugin version 1.2.0 as it now uses env variables (due to changes in jenkins)

I found the solution in a jenkins issue, JENKINS-34700, in particular this comment. The solution consists in using jenkins Shared Objects Plugin to share a groovy script between jobs, where the script do the following:

1. check if environment variables ("gitlabSourceBranch" and "gitlabTargetBranch") are set by gitlab webhook
2. if so update job parameters ("source_branch" and "target_branch")

Not being familiar with EnvInject and SharedObjects, it took me a while to get it to work though, so here it is:

1. install Shared Objects Plugin
2. in “manage jenkins > shared objects”, and add a “Groovy script” shared object, with essentially the content given in the comment (below, a slightly modified version I used)

3. configure your jobs:

   • define parameters “source_branch” and “target_branch” (or only “source_branch” if that's the only thing you need) and use those instead of ${gitlabSourceBranch} and ${gitlabTargetBranch} in your job configuration.
   • in the “General” section, check “Prepare an environment for the run”, and in the “EnvInject Contributions” of what appears then, check “Populate Shared Objects”

Below the content of the Shared Objects groovy script

import hudson.model.*

def build= Thread.currentThread()?.executable
def env = build.properties.get('envVars')
def map = [:]
def source = env['source_branch']
def target = env['target_branch']
if(env['gitlabSourceBranch'] != null) {
  source = env['gitlabSourceBranch']
}
if(env['gitlabTargetBranch'] != null) {
  target = env['gitlabTargetBranch']
}

map['source_branch'] = source
map['target_branch'] = target

def currentActions= build.getAction(ParametersAction.class)
def curParams= currentActions.getParameters()
List<ParameterValue> newParams = []
curParams.each() {
  println it.name
  if (it.name.equals("source_branch")) {
    newParams.add(new StringParameterValue("source_branch", source))
  }
  else if (it.name.equals("target_branch")) {
    newParams.add(new StringParameterValue("target_branch", target))
  }
  else {
    newParams.add(it)
  }
}

build.actions.remove(currentActions)
newActions = new ParametersAction(newParams)
build.actions.add(newActions)
build.save()

return map

[omehegan]

@SilentTiger please let me know if the above comment resolves your issue. But I have a feeling that your problem is something different.

[pvginkel]

This may be a different problem. If you look at the post from GitLab, it looks as follows:

"repository": {
  "name": "ino",
  "url": "git@...",
  "description": "",
  "homepage": "https:\/\/...,
  "git_http_url": "https:\/\/...",
  "git_ssh_url": "git@...",
  "visibility_level": 0
}

In the plugin, the "url" property is used to indicate the source repository. However, when the Git checkout is configured to fetch from https://, it won't match the "url" since that's an SSH URL.

I've actually tested this using a custom build (see https://github.com/pvginkel/gitlab-plugin/commit/f1bd7748d158de7210f76f767e0a7ce7b639cb4d) and changing this got rid of the error message. Problem though is that this changes a default which will break everyone that is using SSH to pull from the repository. So, no pull request yet since this probably needs to become a configuration option and I'm not sure how to do this.

[omehegan]

@pvginkel that is yet another different issue. Can you file it separately? It's something we should look into.

[pvginkel]

Done: https://github.com/jenkinsci/gitlab-plugin/issues/477.

[DavidKuna]

Since I've updated Jenkins and GitLab Plugin to lates version I have the same problem as @SilentTiger.
I've checked @omehegan solution but it's not the same issue what I and @SilentTiger have.

I think, the problem is not in overwriting variables source_branch and target_branch. Value of my $GIT_BRANCH env. variable is origin/dk-test-jenkins and correct branch is checked out. (only if I no Branch Specifier (blank for 'any') is set).

git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
git config remote.origin.url http://gitlab/team-vip/my-project.cz.git # timeout=10
Fetching upstream changes from http://gitlab/team-vip/my-project.cz.git
git --version # timeout=10
using GIT_ASKPASS to set credentials Deploy
git fetch --tags --progress http://gitlab/team-vip/my-project.cz.git +refs/heads/:refs/remotes/origin/
skipping resolution of commit remotes/origin/dk-test-jenkins, since it originates from another repository
Seen branch in repository origin/devel
Seen branch in repository origin/dk-test-jenkins
Seen branch in repository origin/feature/extensible-set-item-quantity
....
Seen 16 remote branches
git show-ref --tags -d # timeout=10
Checking out Revision 1fe2247345308cb197cca76b3dcb6324e7aabfe6 (origin/dk-test-jenkins)
git config core.sparsecheckout # timeout=10
git checkout -f 1fe2247345308cb197cca76b3dcb6324e7aabfe6

@omehegan Any idea what to do, please?

[rvollmar]

I realize this is closed, but I had the same issue and since this came in near the top of the Google results, thought I would share. @pvginkel's comment got me on the right track. In Manage Jenkins > Configure System, I was using https://... for the shared library. Then elsewhere I was using git@... Once I change the one in Manage Jenkins > Conifgure System to git@..., the error no longer occurred.

[koverly]

I'm experiencing the same issue but only with tags. I looked at Manage Jenkins -> Configure System per @rvollmar suggestion, however I don't see anything about "https:// for the shared library". The only git configuration parameters I see in Configure System are "Global Config user.name Value" and "Global Config user.email Value".

The console output is:

git.exe fetch --tags --progress git@st-gitlab:APS/airpouch-600-control.git +refs/heads/:refs/remotes/origin/ +refs/merge-requests//head:refs/remotes/origin/merge-requests/ +refs/tags/:refs/remotes/origin/tags/
skipping resolution of commit refs/tags/0.6, since it originates from another repository
git.exe rev-parse "refs/remotes/origin/refs/tags/0.6^{commit}" # timeout=10
git.exe rev-parse "refs/remotes/origin/origin/refs/tags/0.6^{commit}" # timeout=10
git.exe rev-parse "origin/refs/tags/0.6^{commit}" # timeout=10
ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

EDIT: I think I understand the shared library reference now. It refers to Global Pipeline Libraries which I am not using. The job that produced the above output is a Freestyle project.

[bjmi]

There is a simple workaround to use both GitLab Webhook build triggers and parametrized build and avoid
skipping resolution of commit ...., since it originates from another repository
problem.

1. Edit your job
2. Clear "This project is parameterized" -> "Git Parameter" -> "Default Value" field even if the warning "Default Value is required. Example origin/master" appears.

Build log prints

git rev-parse origin/mybranch^{commit} # timeout=10
Checking out Revision 0c5d066b0420e448a1369ac29d970ff5ccb35284 (origin/mybranch)

again.

Drawback: a manual build requires a selection of a branch now.