You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying to verify the CLAHub setup for Molajo/Filesystem - specifically, Molajo/Filesystem#2. That project is using TravisCI, so #27 still applies here and we'll currently only see one status indicator at a time (Travis or CLAHub) for a given pull.
It could have been that CLAHub was running on a single Heroku Dyno and did not spin up in time, or that the processing simply took too long.
Ideally GitHub webhooks would retry if given a non-2xx response. Absent that, we should ensure CLAHub always has at least 1 dyno. Since Heroku also imposes a 30-second limit on response time, we likely also want to background all webhook responses, similar to #1.
The text was updated successfully, but these errors were encountered:
@AmyStephen if you get a moment, could you do me a favor and try going to Molajo/Filesystem settings > Service Hooks > WebHook URLs and clicking "Test Hook"?
And then see if Molajo/Filesystem#2 gets a CLAHub status? It might not right away (because of TravisCI maybe overwriting it), but I'm curious for you to try it. Thanks!
I'm trying to verify the CLAHub setup for Molajo/Filesystem - specifically, Molajo/Filesystem#2. That project is using TravisCI, so #27 still applies here and we'll currently only see one status indicator at a time (Travis or CLAHub) for a given pull.
That said, I can see via API access that CLAHub never correctly set a status on Molajo/Filesystem@3636c37 for Molajo/Filesystem#2.
In fact, when GitHub sent a Webhook to CLAHub, CLAHub responded with a 504 Gateway Timeout:
It could have been that CLAHub was running on a single Heroku Dyno and did not spin up in time, or that the processing simply took too long.
Ideally GitHub webhooks would retry if given a non-2xx response. Absent that, we should ensure CLAHub always has at least 1 dyno. Since Heroku also imposes a 30-second limit on response time, we likely also want to background all webhook responses, similar to #1.
The text was updated successfully, but these errors were encountered: