Gitlab-plugin: Pipelines do not post build status to GitLab

[jmcgeheeiv]

Issue

I cannot get Jenkins pipelines to post test results to GitLab. Below I explain the results I see.

Works with Jenkins 1 Freestyle Jobs

Here I am using the following versions:

• Gitlab plugin version: 1.4.0
• Gitlab version: 8.6.4
• Jenkins version: 1.625.3
• Job type: Freestyle

I selected _Publish build status to GitLab Commit_, and it is working. I can see in Jenkins log that Jenkins is posting to GitLab:

Call GitLab:
HTTP method: POST
URL: http://.../statuses/...
...

In GitLab, I see the test results. This works.

Works with Jenkins 2.0 Freestyle Jobs

Then I tried my new instance of Jenkins:

• Gitlab plugin version: 1.4.0
• Gitlab version: 8.6.4
• Jenkins version: 2.19.2
• Job type: Freestyle

I specified _Publish build status to GitLab Commit_, and once again, I see the test results in GitLab. This demonstrates that the versions all work together and that my Jenkins 2.0 instance is properly set up to authenticate and communicate with GitLab.

Does not Work With Pipeline or Multibranch Pipeline

This test was performed using the same software versions as the above, but using a pipeline:

• Gitlab plugin version: 1.4.2
• Gitlab version: 8.6.4
• Jenkins version: 2.19.2
• Job type: Pipeline, Multibranch Pipeline

My ultimate goal is to use Jenkins 2.0 with Multibranch Pipeline. I put gitlabCommitStatus in the Jenkinsfile (included below) but it has no effect. In the Jenkins log, I see GitLab triggering Jenkins, and Jenkins runs the job correctly. However, the Jenkins log contains no messages about posting to GitLab. The GitLab build status is not updated.

For completeness, I also created a (non-multibranch) Pipeline job and specified a _Pipeline Script_ instead of a Jenkinsfile. The pipeline script is very similar to the Jenkinsfile shown below. Just as with the Multibranch Pipeline, the script ran properly, but it failed to send its build status to GitLab.

gitlabCommitStatus has no effect.

Logs & Traces

Here is my Jenkinsfile. In this version, stage wdef is set to always fail:

properties: [[$class: 'GitLabConnectionProperty', gitLabConnection: 'gitlab']]

node("sw") {
    stage('setup') {
        deleteDir()
        checkout scm
        // Make sure to unstash within subdirectory wtest using dir("wtest")
        stash name: 'wtest'

        checkout(changelog: true, poll: true,
            scm: [$class: 'GitSCM', branches: [[name: '*/master']],
                  browser: [$class: 'GitLab', repoUrl: 'http://gitlab.wcorp.com/', version: '8.6'],
                  doGenerateSubmoduleConfigurations: false,
                  extensions: [[$class: 'WipeWorkspace'], [$class: 'RelativeTargetDirectory',
                  relativeTargetDir: 'wcore']], submoduleCfg: [],
                  userRemoteConfigs: [[url: 'git@wcorp:sw/wcore.git']]
                 ])
        stash includes: 'wcore/**', name: 'wcore'
    }

    stage('wabc') {
        deleteDir()
        dir("wtest") {
            unstash 'wtest'
         }
        unstash 'wcore'
        gitlabCommitStatus {
            sh '$JENKINS_HOME/wave/bin/inspectexpects.sh wtest/test/wabc_expects.txt'
        }
    }

    stage('wdef') {
        deleteDir()
        dir("wtest") {
            unstash 'wtest'
         }
        unstash 'wcore'

        gitlabCommitStatus("wfgsim") {
            sh 'exit 1'   // Force a failure
            // sh '$JENKINS_HOME/wave/bin/inspectexpects.sh wtest/test/wdef_expects.txt'
        }
    }
    stage('wghi') {
        deleteDir()
        dir("wtest") {
            unstash 'wtest'
         }
        unstash 'wcore'

        gitlabCommitStatus {
            sh '$JENKINS_HOME/wave/bin/inspectexpects.sh wtest/test/wghi_expects.txt'
        }
    }

    stage("wjkl") {
        deleteDir()
        dir("wtest") {
            unstash 'wtest'
         }
        unstash 'wcore'

        gitlabCommitStatus {
            sh '$JENKINS_HOME/wave/bin/inspectexpects.sh wtest/test/wjkl_expects.txt'
        }
    }
}

How do I get gitlabCommitStatus to have an effect?

[ljdelight]

This works for me:

...
gitlabBuilds(builds: ['build', 'test', 'artifacts']) {
  stage('build') { gitlabCommitStatus(name: 'build') { // gitlab build and status must match here
    sh "./gradlew --no-daemon clean build"
  }
  ... // do the others, 'test' and 'artifacts'
}

[omehegan]

@jmcgeheeiv are you still having this issue? If so, can you try using this syntax for your 'properties' line in your Jenkinsfile:
properties([[$class: 'GitLabConnectionProperty', gitLabConnection: '

[jmcgeheeiv]

Thank you for your suggestions. Yes, I am still having this problem.

• I modified my usage of gitlabCommitStatus() as suggested by @ljdelight. The behavior did not change.
• Additionally, I modified the properties line as suggested by @omehegan, and the behavior did not change.

I checked the GitLab Plugin log, and I still do not see any Call GitLab messages. I got pulled off to another project, but I think I may have to dig into the source code myself to see if I can find the problem. If you had a moment to point out the most likely source files, that would help.

[ljdelight]

I documented how to setup a gitlab+jenkins CI environment and build on every merge request over here. You might skim it to see if anything obvious is missing on your side.

[omehegan]

@jmcgeheeiv there are different ways of sending the status, the one you specified in your original example should be fine. I would suggest looking at your GitLab HTTP log to see if it sees the request from Jenkins/the plugin to post status. Then we can figure out if that request is just being discarded or what.

This type of problem is most commonly associated with people using a proxy server between Jenkins and GitLab. Also, have you confirmed that your connection to GitLab from Jenkins works, using the 'test' button in the Jenkins global config?

[jmcgeheeiv]

I really appreciate your attention.

@omehegan, I tried the Test Connection button, and it displayed "Success". Also note that as I originally reported, GitLab notifications work with freestyle jobs, proving that Jenkins can talk to GitLab. The problem is with MultiBranch pipelines only.

Could you help me out with what to look for in which log file? With so many log files, and not knowing exactly what to look for, the files are difficult to examine.

[omehegan]

@jmcgeheeiv ok, it's interesting that it works in Freestyle but not Pipelines.

If you have installed GitLab from their package, look at the /var/log/gitlab/nginx/gitlab_access.log for 'GET /api ...' requests. You should see things like
GET /api/SOMEPROJECT/merge_requests/132/ci_status

If you see those when a Pipeline build is running and sending status, we know at least that it's successfully sending the status to GitLab.

I would also suggest that you try creating a very simple test Pipeline job that doesn't really build anything, just has one stage, and sends a simple status back. Something like this:

properties([[$class: 'GitLabConnectionProperty', gitLabConnection: 'YOUR_GITLAB_CONNECTION_NAME']])
node() {
  checkout scm
  gitlabCommitStatus {
    sh 'echo "Testing"'
  }
}

That would help us isolate whether this is just a configuration issue or not.

[omehegan]

@jmcgeheeiv hmmm, can you also tell me what version of the Pipeline plugins you are using? I wonder if you are hitting some kind of bug or missing feature in those.

[omehegan]

@jmcgeheeiv can you also look at the Pipeline Steps view of a job which completed but did not send status to GitLab? There should be a step listed in there that says something like, 'Update the commit status in GitLab depending on the build status' If that is missing then we know Jenkins isn't even trying to send the status.

[jmcgeheeiv]

Thank you for your guidance, and sorry for the delay, @omehegan. I had to, you know, do what the boss wanted done ;-).

In GitLab I created a repository called gitlabcommitstatus. It contains a Jenkinsfile with the simple script that you proposed. In Jenkins I created job gitlabCommitStatus.pipeline that executes it.

The Jenkins _Pipeline Steps_, step _Update the commit status in GitLab depending on the build status_ console output was particularly revealing. Apparently Jenkins is trying to send something that is not proper JSON:

Failed to update Gitlab commit status for project '43': java.lang.RuntimeException: com.fasterxml.jackson.core.JsonParseException: Illegal character ((CTRL-CHAR, code 31)): only regular white space (\r, \n, \t) is allowed between tokens
 at [Source: ���1O�0��J�4�ۤ$R%�nU������(���sV�V�޽������U]B�=�=X�Umʭz<��A�[,��Zn�xq�:���)9���UJ��);`���#f
v��,��|f��~��.�+q�)�O�i�K��⯈
����w}R�>�=%�~��-���&-�>�*W��vMY7Ro�)���L�
c����-�a �cS��a5�����ٹ4
����..�c��4�ΰ`Hg��y}cd���m��۝��GZ�Lī�g����p�U�
; line: 1, column: 2]

Here are the GitLab log messages from the time at which I ran the test. The GET /api string does occur:

192.168.6.50 - - [12/Jan/2017:15:01:34 -0800] "GET /jmcgehee/gitlabcommitstatus/hooks/53/test HTTP/1.1" 302 131 "http://infra2.wavesemi.com:8096/jmcgehee/gitlabcommitstatus/hooks" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36"
192.168.6.50 - - [12/Jan/2017:15:01:34 -0800] "GET /jmcgehee/gitlabcommitstatus/hooks HTTP/1.1" 200 4893 "http://infra2.wavesemi.com:8096/jmcgehee/gitlabcommitstatus/hooks" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36"
10.14.10.59 - - [12/Jan/2017:15:01:46 -0800] "GET /api/v3/projects/43/repository/commits/695a6acdfd7adbe69b5318fb122bea23e5749030 HTTP/1.1" 200 303 "-" "-"
10.14.10.59 - - [12/Jan/2017:15:01:46 -0800] "GET /api/v3/projects/43/repository/commits/695a6acdfd7adbe69b5318fb122bea23e5749030 HTTP/1.1" 200 303 "-" "-"
192.168.6.50 - - [12/Jan/2017:15:05:41 -0800] "GET /jmcgehee/gitlabcommitstatus HTTP/1.1" 200 6248 "http://infra2.wavesemi.com:8096/jmcgehee/gitlabcommitstatus/hooks" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36"

Finally, here are all the Pipeline plugin versions:

• Pipeline 2.4
• Pipeline Graph Analysis Plugin 1.2
• Pipeline: API 2.8
• Pipeline: Basic Steps 2.2
• Pipeline: Build Step 2.3
• Pipeline: Groovy 2.23
• Pipeline: Input Step 2.3
• Pipeline: Job 2.8
• Pipeline: Milestone Step 1.1
• Pipeline: Multibranch 2.9
• Pipeline: Nodes and Processes 2.5
• Pipeline: REST API Plugin 2.1
• Pipeline: SCM Step 2.2
• Pipeline: Shared Groovy Libraries 2.5
• Pipeline: Stage Step 2.2
• Pipeline: Stage View Plugin 2.1
• Pipeline: Step API 2.5
• Pipeline: Supporting APIs 2.10

Again, many, many thanks for your help.

[Bessonov]

After we upgrade Jenkins to 2.41 and all Plugins, we got same Problem. Downgrade gitlab plugin from 1.4.4 back to 1.3.0 helps (tested with Pipeline).

[omehegan]

@jmcgeheeiv that's really strange that you are getting this garbage in your commit status update attempt. I have no idea what could cause that :/ Can you tell me what version of Java you are running Jenkins under? I'm really grasping at straws here, but it seems like there is something unusual about your local environment.

[skobarx]

Hi all,
I have the same issue with multibranch pipeline project.
My jenkinsfile has the following code:

post{
        success{
                echo 'update commit status'
                script{
                    gitLabConnection('git_sami')
                    updateGitlabCommitStatus(name: 'build', state: 'success')
                }
        }

Everything works perfect in Freestyle project.

Gitlab plugin version: 1.4.5
Gitlab CE version: 8.16.6
Jenkins version: 2.48
Job type: Multibranch Pipeline

[jmcgeheeiv]

Sorry for the long silence. I downgraded to GitLab Plugin version 1.3.0 as suggested by @Bessonov, but the problem remains:

Failed to update Gitlab commit status for project 'jmcgehee/gitlabcommitstatus': java.lang.RuntimeException: com.fasterxml.jackson.core.JsonParseException: Illegal character ((CTRL-CHAR, code 31)): only regular white space (\r, \n, \t) is allowed between tokens
 at [Source: ��Q=o�0�+,/up)��-@�L���x��F�C��P���ݒ���{�{�?t
z�
R
-�j��w�g
��F
�4�����Ϻ��\���[c}ft���j̘�6�Zm3�\�ԍ��.��R9o�Ydx�2�p^�_�SRwt�'� ��}��"���i��Wr   �2c�p�*�L��5݃�;�v���-H
B��<~t�}��}z�&�[
UZj�"a�K*+��*���{f�˾�c_}Z�;c��W��QC�

�� �x��:��@�f짮���5���޷F�
�L���
�m�0z�UY�9�5� ɼ#����~~�X/�@�o�|��~pPϛH; line: 1, column: 2]

Some day maybe I can bring this up in a debugger and see what is going on.

[jmcgeheeiv]

@omehegan, you asked about my Java version. I was surprised to find that it is OpenJDK, not Oracle Java:

/usr/bin/java -version
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-8u121-b13-0ubuntu1.16.04.2-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)

Should I be using a different Java, like Oracle Java?

For reference, I used the following methodology to make sure that /usr/bin/java really is the Java that Jenkins is using:

grep -i java /etc/default/jenkins /etc/init.d/jenkins
    ...
JAVA=/usr/bin/java
    ...
    $SU -l $JENKINS_USER --shell=/bin/bash -c "$DAEMON $DAEMON_ARGS -- $JAVA $JAVA_ARGS -jar $JENKINS_WAR $JENKINS_ARGS" || return 2
    ...

[omehegan]

No, OpenJDK should be fine. I use it. I'm sorry that I don't have any other ideas about this :(

[ottochiu]

Are there any updates to this issue? I ran into this exact same problem and ended up writing scripts to make API calls to Gitlab at each stage.

[omehegan]

Sounds like a bug, but I'm really at a loss for what could cause what looks like data corruption here. Maybe you two could compare notes about your environment?

[jmcgeheeiv]

My environment appears above. @ottochiu, could you compare your environment to mine?

[jotomo]

@skobarx Based on your _post_ section I added a _failure_ part that updates GitLab in case of failure. This works for me. I think this is a different issue than what @jmcgeheeiv is seeing though, as the POST is succesful, rather than having garbage payload. But it might be worth a try as a workaround for either case. Here's what I came up with:

  post {
    success {
      echo 'posting success to GitLab'
          updateGitlabCommitStatus(name: 'jenkins-build', state: 'success')
    }
    failure {
      echo 'postinng failure to GitLab'
          updateGitlabCommitStatus(name: 'jenkins-build', state: 'failed')
    }
  }

(Note that the GitLab API doesn't use _failure_ to indicate failure. _success_ is the odd one out, which should be _succeeded_ to be consistent, see https://docs.gitlab.com/ce/api/commits.html#post-the-build-status-to-a-commit).

@jmcgeheeiv The exception you see is _JsonParseException_: is the exception from trying to parse what the server returns? Nasty proxy sitting in between?

HTH

[jmcgeheeiv]

@jotomo, your observation about _JsonParseException_ is very interesting; I did not notice how this suggests that the JSON is coming _in_ to Jenkins.

To answer your question, I do not have any proxy in between Jenkins and GitLab.

[omehegan]

@jmcgeheeiv I hadn't thought of this either. Maybe you could use wireshark to capture this response as received on the Jenkins host, and as sent from GitLab, and see if they match.

[ottochiu]

@jmcgeheeiv - sorry I was on vacation. This is my Java version:

/usr/bin/java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

I should point out that this works in regular freestyle jobs. Multibranch pipeline jobs are the only ones that isn't able to post statuses to Gitlab.

[jmcgeheeiv]

@ottochiu, yes, my experience with freestyle/multibranch pipelines is identical to yours.

[omehegan]

I'm guessing that whatever causes this is specific to your environment. Since we don't have any further data, I'll close it for now.

[QAston]

Having the same issue - publishing works with freestyle jobs, doesn't work with pipeline/multibranch jobs.
Jenkins version: 2.21, plugins:
--- 'jenkins::plugins': 'ace-editor': version: '1.1' 'analysis-core': version: '1.87' 'ansicolor': version: '0.4.2' 'ant': version: '1.4' 'antisamy-markup-formatter': version: '1.5' 'authentication-tokens': version: '1.3' 'bouncycastle-api': version: '2.16.0' 'branch-api': version: '2.0.9' 'build-monitor-plugin': version: '1.11+build.201701152243' 'cloudbees-folder': version: '6.0.4' 'cobertura': version: '1.10' 'conditional-buildstep': version: '1.3.5' 'config-file-provider': version: '2.16.0' 'cors-filter': version: '1.1' 'credentials': version: '2.1.13' 'credentials-binding': version: '1.11' 'display-url-api': version: '0.3' 'docker-commons': version: '1.6' 'docker-workflow': version: '1.9' 'durable-task': version: '1.14' 'email-ext': version: '2.57.2' 'emma': version: '1.29' 'envinject': version: '1.93.1' 'external-monitor-job': version: '1.6' 'git': version: '3.4.1' 'git-client': version: '2.4.6' 'git-parameter': version: '0.8.0' 'git-server': version: '1.7' 'gitlab-plugin': version: '1.4.7' 'gradle': version: '1.26' 'groovy': version: '2.0' 'groovy-postbuild': version: '2.3.1' 'groovy-remote': version: '0.2' 'handlebars': version: '1.1.1' 'htmlpublisher': version: '1.12' 'icon-shim': version: '2.0.3' 'jacoco': version: '2.2.0' 'javadoc': version: '1.4' 'job-restrictions': version: '0.6' 'jquery': version: '1.11.2-0' 'jquery-detached': version: '1.2.1' 'junit': version: '1.20' 'junit-attachments': version: '1.4.2' 'ldap': version: '1.12' 'm2release': version: '0.14.0' 'mailer': version: '1.18' 'mapdb-api': version: '1.0.9.0' 'matrix-auth': version: '1.4' 'matrix-project': version: '1.11' 'maven-plugin': version: '2.15.1' 'mercurial': version: '1.57' 'momentjs': version: '1.1.1' 'msbuild': version: '1.27' 'multiple-scms': version: '0.6' 'nodejs': version: '1.2.2' 'nunit': version: '0.20' 'pam-auth': version: '1.3' 'parameterized-scheduler': version: '0.4' 'parameterized-trigger': version: '2.35.1' 'persistent-parameter': version: '1.1' 'pipeline-build-step': version: '2.5.1' 'pipeline-graph-analysis': version: '1.4' 'pipeline-input-step': version: '2.7' 'pipeline-maven': version: '2.5.2' 'pipeline-milestone-step': version: '1.3.1' 'pipeline-model-api': version: '1.1.8' 'pipeline-model-declarative-agent': version: '1.1.1' 'pipeline-model-definition': version: '1.1.8' 'pipeline-model-extensions': version: '1.1.8' 'pipeline-multibranch-defaults': version: '1.1' 'pipeline-npm': version: '0.9.1' 'pipeline-rest-api': version: '2.8' 'pipeline-stage-step': version: '2.2' 'pipeline-stage-tags-metadata': version: '1.1.8' 'pipeline-stage-view': version: '2.8' 'plain-credentials': version: '1.4' 'promoted-builds': version: '2.27' 'resource-disposer': version: '0.6' 'run-condition': version: '1.0' 'sbt': version: '1.5' 'scm-api': version: '2.2.0' 'scm-sync-configuration': version: '0.0.10' 'script-security': version: '1.29' 'ssh-agent': version: '1.15' 'ssh-credentials': version: '1.13' 'ssh-slaves': version: '1.11' 'structs': version: '1.9' 'subversion': version: '2.7.1' 'tasks': version: '4.51' 'throttle-concurrents': version: '2.0.1' 'token-macro': version: '2.1' 'toolenv': version: '1.1' 'unleash': version: '2.1.1' 'view-job-filters': version: '1.27' 'windows-slaves': version: '1.2' 'workflow-aggregator': version: '2.5' 'workflow-api': version: '2.19' 'workflow-basic-steps': version: '2.6' 'workflow-cps': version: '2.36.1' 'workflow-cps-global-lib': version: '2.8' 'workflow-durable-task-step': version: '2.12' 'workflow-job': version: '2.11.1' 'workflow-multibranch': version: '2.16' 'workflow-scm-step': version: '2.5' 'workflow-step-api': version: '2.12' 'workflow-support': version: '2.14' 'ws-cleanup': version: '0.30'

[jmcgeheeiv]

Multiple people continue to encounter this issue. I do not see why this issue should be closed.

[omehegan]

We can leave it open, but I can't seem to make any progress understanding what the cause is.

FWIW, the plugin has 14,400 installs currently. I see 5 people experiencing this issue. Many people, including me, use the plugin with Pipeline and Pipeline Multibranch jobs and sending status to GitLab works. That's why I feel like the root cause must be something outside the scope of the plugin itself.

[Tibor17]

@omehegan
You should traverse changes between version 1.3.0 and 1.4.4. It looks like encoding issue.
16bit characters encoded with utf-8 written to us-ascii 8 bit character, that's why @jmcgeheeiv has the marks �. Another question to @jmcgeheeiv and @skobarx . Did you upgrade Jenkins together with this plugin?

[martinpritchard]

This may or may not be related, but I have experienced issues with updateGitlabCommitStatus working on some pipeline projects and not others. Strangely, this turned out to be main Configuration for the pipeline requiring the .git suffix in Project Repository setting (Configure/Branch Sources/Git/Project Repository), so:

git@repo:group/project updateGitlabCommitStatus would not work

git@repo:group/project.git updateGitlabCommitStatus would work

The jobs build and work fine using both ways, but you see nothing in the Gitlab Pipeline view unless you include the .git suffix.

[jmcgeheeiv]

@martinpritchard,
Thank you very much for your insight. I did have the problem described in this issue, and my pipeline configuration Project Repository field does not contain ".git". So it is possible that you found the cause of my problem.

However, as part of the diagnosis of an unrelated problem, I removed updateGitlabCommitStatus from my Jenkinsfile, so I cannot verify. I need to put it back and try again.

[omehegan]

@martinpritchard excellent observation. Maybe this is a regex issue, although you'd think we would have noticed it sooner if it were something this "obvious," in the sense that it must be about 50/50 whether someone uses a .git URL or not.

[rsommer]

I can confirm that the missing .git at the end of the repo URL does indeed trigger the described behaviour. We are using jenkins 2.8x and gitlab ce 10. After adding .git to the repo url on two jenkins multibranch-pipeline jobs that were not reporting commit status back to gitlab everything worked again.

[jmcgeheeiv]

@martinpritchard is a rock star!

[aschlei]

We are having a similar issue. We have .git on the repos in Jenkins so that's not the issue for us. I've tried a few things from this thread, but so far no luck.

However, I did notice something strange in the gitlab_access.log. I was looking for POST requests and it does appear this are being triggered by the build (the timestamps line up with test builds I have been doing). However, all the requests seem to go to the same URL for a merge commit in a different repo. Actually, it seems that all the status updates for all projects try to post to this same commit. This commit was from a couple months ago, but our problem with the status not showing up in GitLab is older than that.

So in the log I see:
POST /api/v3/projects/group%2Fproject/statuses/commit HTTP/1.1
Over and over again, with the exact same group, project, and commit hash every time.

That commit keeps getting set to pending, but never to success or failed.

[PW999]

So, I'm having the same problem, no updates in gitlab from Jenkins and I see the following errors in my nginx reverse proxy access log

172.18.0.3 - - [25/Feb/2018:20:08:22 +0000] "GET /scripts/cat.git/info/refs?service=git-receive-pack HTTP/1.1" 401 26 "-" "git/2.11.0"
172.18.0.3 - - [25/Feb/2018:20:08:22 +0000] "GET /scripts/cat.git/info/refs?service=git-receive-pack HTTP/1.1" 401 26 "-" "git/2.11.0"
172.18.0.3 - jenkins [25/Feb/2018:20:08:23 +0000] "GET /scripts/cat.git/info/refs?service=git-receive-pack HTTP/1.1" 200 1187 "-" "git/2.11.0"
172.18.0.3 - jenkins [25/Feb/2018:20:08:23 +0000] "POST /scripts/cat.git/git-receive-pack HTTP/1.1" 200 47 "-" "git/2.11.0"
172.18.0.3 - - [25/Feb/2018:20:08:23 +0000] "GET /api/v4/projects/scripts%2Fcat/repository/commits/27c025bd2528c9a0b8c26891aa246022d5fca2dd HTTP/1.1" 404 25 "-" "-"
172.18.0.3 - - [25/Feb/2018:20:08:24 +0000] "GET /api/v4/user HTTP/1.1" 200 683 "-" "-"
172.18.0.3 - - [25/Feb/2018:20:08:24 +0000] "GET /api/v4/projects/scripts%2Fcat/repository/commits/27c025bd2528c9a0b8c26891aa246022d5fca2dd HTTP/1.1" 404 25 "-" "-"

However, when I change the gitlab connection URL so that it connects directly to gitlab and not through a reverse-proxy, then all of a sudden it works :+1:

This is my nginx reverse proxy config

    server {
        listen       8080;
        server_name  gitlab.local;

        client_max_body_size 100m;

        location / {
                proxy_pass http://gitlab.internal/;
                access_log /var/log/nginx/access_gitlab.log;
                proxy_set_header   Host             $host:8080;
                proxy_set_header   X-Real-IP        $remote_addr;
                proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
                #proxy_set_header   X-Forwarded-Proto $scheme;
                proxy_max_temp_file_size 0;
                #this is the maximum upload size
                client_max_body_size       10m;
                client_body_buffer_size    128k;

                proxy_connect_timeout      90;
                proxy_send_timeout         90;
                proxy_read_timeout         90;


        }
}

//edit: so, I removed the slash in the proxy_pass

    server {
        listen       8080;
        server_name  gitlab.local;

        client_max_body_size 100m;

        location / {
                proxy_pass http://gitlab.internal;

Seems to work now, with both the internal and external url configured in Jenkins.
Maybe due to nginx handling these differently: https://serverfault.com/a/463932

[omehegan]

I have built a patch release of the plugin which fixes the regex so that .git is not required in the git URI. We think this resolves this bug for most people. Please test:

http://repo.jenkins-ci.org/snapshots/org/jenkins-ci/plugins/gitlab-plugin/1.5.6-SNAPSHOT/gitlab-plugin-1.5.6-20180411.042719-1.hpi

[omehegan]

@aschlei it sounds like the problem you reported is caused by something else. If you are still experiencing a problem, please open a new issue.

[omehegan]

I believe this was fixed with a regex update. Please see #691 for updates when this is released (hopefully later today).