GiLlab can't pull build status from Drone CI

Summary

When integrating Drone CI version 0.7 with GitLab, the build status always shows as pending. Also, using Test Service from the settings page shows a "500 - Whoops, something went wrong on our end." page.

Steps to reproduce

1. Setup a Drone CI server version 0.7 and configure it to use GitLab.
2. Setup a GitLab project, and add it to Drone CI.
3. Add a .drone.yml file and push it to the repo.

Example Project

https://gitlab.com/xvh/drone-ci-test

What is the current bug behavior?

The build is started on Drone CI (typically two or three times) and is completed successfully, but the build status in GitLab still shows as Pending.

When the Test Service button is clicked a "500 - Whoops, something went wrong on our end." page is shown.

What is the expected correct behavior?

The build is started once. Once the build is started, it shows as running in GitLab. When the build is completed, it shows as successful.

When the Test Service button is clicked, it should show a success page saying the build was started.

Output of checks

This bug happens on GitLab.com

+1 same to me :(

Gitlab Version: 9.1.4 gitlab-foss@fed799ae. Drone Version: 0.7.

The associated exception in our error tracking system:

Net::ReadTimeout: Net::ReadTimeout
  from net/protocol.rb:158:in `rbuf_fill'
  from net/protocol.rb:136:in `readuntil'
  from net/protocol.rb:146:in `readline'
  from net/http/response.rb:40:in `read_status_line'
  from net/http/response.rb:29:in `read_new'
  from net/http.rb:1437:in `block in transport_request'
  from net/http.rb:1434:in `catch'
  from net/http.rb:1434:in `transport_request'
  from net/http.rb:1407:in `request'
  from net/http.rb:1400:in `block in request'
  from net/http.rb:853:in `start'
  from net/http.rb:1398:in `request'
  from httparty/request.rb:117:in `perform'
  from httparty.rb:545:in `perform_request'
  from httparty.rb:492:in `post'
  from app/models/hooks/web_hook.rb:26:in `execute'
  from app/models/hooks/service_hook.rb:5:in `execute'
  from app/models/project_services/drone_ci_service.rb:23:in `execute'

Are there any logs of the request on the Drone server, it appears we're hitting a timeout waiting for a response from Drone

Thank you Mark for checking.

I've checked the logs of the NGINX proxy and when clicking Test Service the following request was logged (access token obfuscated):

13.68.92.26 - - [02/Jun/2017:12:15:21 +0000] "POST /api/hook?owner=xvh&name=drone-ci-test&access_token=XXX.XXX.XXX HTTP/1.1" 499 0 "-" "-"

The 499 status code means "Client Closed Request", which implies to me that GitLab terminated the connection before it was completed.

I've simulated a request myself as well and it took 13.6 seconds for the request to complete. What's the maximum request time for GitLab?

@xvh The timeout is configurable. The timeout defaults to 10 seconds. Configure it here:

Omnibus:

/etc/gitlab/gitlab.rb

gitlab_rails['webhook_timeout'] = 15

Source:

config/gitlab.yml

## Webhook settings
# Number of seconds to wait for HTTP response after sending webhook HTTP POST request (default: 10)
webhook_timeout: 15

Thanks for the suggestion, I'm sure it will work just fine for self hosted installations.

However, I'm using GitLab.com for the repositories I want to use Drone for as well, meaning I don't have access to those settings. Any other suggestions?

Solved my problem!

But NOT the webhook_timeout. It's Drone's config DRONE_HOST, MUST be provided protocol http or https.

this's my config before.

web:
    image: drone/drone:0.7
    volumes:
      - ci-data:/var/lib/drone/
    environment:
      - DRONE_OPEN=true
      - DRONE_HOST=xxx.xxx
      - DRONE_GITLAB=true
      - DRONE_GITLAB_CLIENT=xxxxxx
      - DRONE_GITLAB_SECRET=xxxxxx
      - DRONE_GITLAB_URL=http://gitlab.xxx

and changed after.

web:
    image: drone/drone:0.7
    volumes:
      - ci-data:/var/lib/drone/
    environment:
      - DRONE_OPEN=true
      - DRONE_HOST=http://xxx.xxx
      - DRONE_GITLAB=true
      - DRONE_GITLAB_CLIENT=xxxxxx
      - DRONE_GITLAB_SECRET=xxxxxx
      - DRONE_GITLAB_URL=http://gitlab.xxx

Hope this helps. :)

@xvh Please can you provide an update for this issue?

@markglenfletcher I'm happy to provide an update but nothing has changed, really.

The solution provided by @brainet didn't work for me (I already had the protocol specified in my docker-compose.yml and it didn't affect the issue).

Right now, the number of build retries varies a lot. Some builds are tracked correctly and are only fired once, other builds execute 5-10 times. The build status callback does work, after the build has completed on Drone the status on GitLab is updated as well. However, by then it will have started multiple builds already because GitLab was never able to verify the builds had started.

The number of builds started for a commit seem to correlate with the speed of the Drone interface. Sometimes Drone feels snappy and runs only one build. Sometimes it takes 5+ seconds to load the repositories list and it runs 3 builds for a commit. I guess that's the price I have to pay for using a cheap VPS with too many workers ;)

I do believe the solution suggested by @markglenfletcher is the solution because a webhook timeout sounds likely. However, I'm hosting my regular repositories on gitlab.com, which means I don't have access to those system settings and I can't verify it works.

moved from gitlab-foss#33212 (moved)