Skip to content
Snippets Groups Projects
New issue look: Off

GiLlab can't pull build status from Drone CI

    • Closed (moved) Issue created by username-removed-288342 @xvh

    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

    Designs

    Child items ...

    • Activity

    • username-removed-236110
      username-removed-236110 @brainet ·

      +1 same to me :(

      Gitlab Version: 9.1.4 fed799ae. Drone Version: 0.7.

    • username-removed-419655
      username-removed-419655 @markglenfletcher1 ·
      Developer

      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

    • username-removed-288342
      username-removed-288342 @xvh ·
      Author

      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?

    • username-removed-419655
      username-removed-419655 @markglenfletcher1 ·
      Developer

      @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
    • username-removed-288342
      username-removed-288342 @xvh ·
      Author

      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?

    • username-removed-236110
      username-removed-236110 @brainet ·

      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. :)

      Edited by username-removed-236110
    • username-removed-419655
      username-removed-419655 @markglenfletcher1 ·
      Developer

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

    • username-removed-288342
      username-removed-288342 @xvh ·
      Author

      @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.

    • Felipe Artur moved to gitlab#10239

      moved to gitlab#10239

    • Felipe Artur
      Felipe Artur @felipe_artur ·
      Maintainer

      Hey! :wave:

      GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

      If you have any questions about all of this, please ask them in our dedicated FAQ issue.

      https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

      You can also find more information here:

      Frequently Asked Questions

      For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

      What will we do with the repository names?

      https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

      Why rename gitlab-ce to gitlab-foss?

      Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

      I created a merge requests for CE, and this got closed. What do I need to do?

      You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

      How does the licensing work in this new setup?

      Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

      Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

      No. Merge requests submitted to this project will be closed automatically.

      Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

      Yes.

      How will this affect users of GitLab CE using Omnibus?

      No changes will be necessary, as the packages built remain the same.

      How will this affect users of GitLab CE that build from source?

      Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

      Where can I see a timeline of the remaining steps?

      https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

      Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

      Yes, these changes will be synced to gitlab-foss automatically, several times per day.

    • Felipe Artur locked this issue

      locked this issue

    Please register or sign in to reply