Commit f4e0c562 authored by Jacob Vosmaer's avatar Jacob Vosmaer

Improve documentation and web test for web hooks

I wanted to share what I learned trying to debug web hooks using
netcat.
parent f0c4f727
...@@ -28,7 +28,7 @@ class Projects::HooksController < Projects::ApplicationController ...@@ -28,7 +28,7 @@ class Projects::HooksController < Projects::ApplicationController
status, message = TestHookService.new.execute(hook, current_user) status, message = TestHookService.new.execute(hook, current_user)
if status if status
flash[:notice] = 'Hook successfully executed.' flash[:notice] = "Hook successfully executed, HTTP #{status} #{message}"
else else
flash[:alert] = "Hook execution failed: #{message}" flash[:alert] = "Hook execution failed: #{message}"
end end
......
...@@ -59,7 +59,7 @@ class WebHook < ActiveRecord::Base ...@@ -59,7 +59,7 @@ class WebHook < ActiveRecord::Base
basic_auth: auth) basic_auth: auth)
end end
[(response.code >= 200 && response.code < 300), ActionView::Base.full_sanitizer.sanitize(response.to_s)] [response.code, ActionView::Base.full_sanitizer.sanitize(response.to_s)]
rescue SocketError, OpenSSL::SSL::SSLError, Errno::ECONNRESET, Errno::ECONNREFUSED, Net::OpenTimeout => e rescue SocketError, OpenSSL::SSL::SSLError, Errno::ECONNRESET, Errno::ECONNREFUSED, Net::OpenTimeout => e
logger.error("WebHook Error => #{e}") logger.error("WebHook Error => #{e}")
[false, e.to_s] [false, e.to_s]
......
...@@ -13,6 +13,19 @@ You can configure webhooks to listen for specific events like pushes, issues or ...@@ -13,6 +13,19 @@ You can configure webhooks to listen for specific events like pushes, issues or
Webhooks can be used to update an external issue tracker, trigger CI builds, update a backup mirror, or even deploy to your production server. Webhooks can be used to update an external issue tracker, trigger CI builds, update a backup mirror, or even deploy to your production server.
## Webhook endpoint tips
If you are writing your own endpoint (web server) that will receive
GitLab web hooks keep in mind the following things:
- Your endpoint should send its HTTP response as fast as possible. If
you wait too long, GitLab may decide the hook failed and retry it.
- Your endpoint should ALWAYS return a valid HTTP response. If you do
not do this then GitLab will think the hook failed and retry it.
Most HTTP libraries take care of this for you automatically but if
you are writing a low-level hook this is important to remember.
- GitLab ignores the HTTP status code returned by your endpoint.
## SSL Verification ## SSL Verification
By default, the SSL certificate of the webhook endpoint is verified based on By default, the SSL certificate of the webhook endpoint is verified based on
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment