GitHub webhook returns 200 response, but body is empty

Drone Support
1

Hi,

I noticed the webhook in GitHub doesn’t trigger a build occasionally.
I checked out the webhook history, and found there is a case when the response status code is 200, but the body is empty. I manually redeliver the same request and verified it was processed so I think it is not caused by data, but timing.

Cursor_and_Webhook_%C2%B7_https___drone-ci_parksidesecurities_io_hook
Cursor_and_Webhook_%C2%B7_https___drone-ci_parksidesecurities_io_hook768×849 71.7 KB

Drone-ci server version:
version: “1.6.0”

Does anyone experience the issue?

2

when Drone ignores a webhook it writes the full reason why to the server logs. We therefore need to see full server logs to answer any questions related to your webhook.

3

Here is the corresponding server log.

{"commit":"b490ca1169a6179695740f32af16c3fef9ee93fb","event":"push","level":"info","msg":"trigger: skipping hook. found skip directive","ref":"refs/heads/master","repo":"parkside-securities/monorepo","time":"2019-10-23T05:37:55Z"}

I looked up the commit message of the SHA b490ca.... We use squash merge so when a PR is merged to master, the commit contains the log of all intermediate commits. I noticed it includes [SKIP CI] directive. So I guess drone-ci scans the entire commit message, and skip the build if such a directive is included anywhere, it observes. Is the assumption correct?

Ledger e2e-test #1c7ac3 (#136)

* Add unsafeFundAccount mutation #1ea68b

* Add unsafe-fund-account streamer

* Publish ledger-request

* [WIP] Try windowed kstream join

* [WIP] Make windowed join streams work

* Add UnsafeFundAccountRequested Event

* Fix UnsafeFundAccountRequested

* [Skip CI] [WIP] Move joined-stream to command-processor
...

I think it’s too much to ask developers to manually inspect and get rid of them. Is it possible to limit the scanning scope only in the first line if that’s the case?

I’m also wondering why redelivering the hook DID trigger the build…

Thanks,

4

Correct

This would be a breaking change, and could negatively impact other teams that may not expect this new behavior. I do not believe we can justify this sort of breaking change at this time.

5

@bradrydzewski I appreciate your quick reply. Make sense for the risk of changing the behavior. it is nice to know and I’ll share the knowledge in my team. Thanks!