-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error forwarding Bitbucket Cloud to Internal Jenkins #116
Comments
Issue-Label Bot is automatically applying the label Links: app homepage, dashboard and code for this bot. |
I noted the issue, and it appears this happens on Github when the Content Type of the hook is set to application/x-www-form-urlencoded. It appears to assume that the body is JSON encoded. (Jenkins appears to throw the java.lang.Throwable: HttpInput idle timeout exception when there is no body in the message sent to github-webhook). |
@mgust Just a heads up, that this was for BitBucket. Maybe it's the same issue? |
Any update on this issue |
Ah, missed that. I suspect it may be something similar though as the error basically just seemed to mean that Jenkins didn't get a body in the trigger.
So basically, the error is upstream. Either BitBucket isn't sending a body to Smee, or the format of the body it sends is malformed and can't be parsed. |
Actually I still believe it's smee that has an issue. I ended up using socketxp instead for relaying and it works well. I have to believe the issue lies with smee. |
I was experiencing the same issue with Jenkins, GitHub, and smee. Changing the Content Type to 'application/json' on the GitHub webook configuration is what finally worked for me. As @mgust indicated, setting the webhook configuration to 'application/x-www-form-urlencoded' does not appear to provide the correct response for Jenkins. Not sure is BitBucket has a similar option. |
Yeah that may well be the issue and unfortunately Bitbucket doesn't let you switch content type. I also think this project has lost traction as it appears the owners haven't replied to anything in quite some time. |
Is this repo is active? |
@yrsurya yes, this just isn't a big problem. Based on this comment from @mgust, it looks like this is due to passing non-JSON data to So, I'd say we have two options:
If any of y'all want to open a PR, happy to review it. Should just be some additions here: Line 19 in 2eb82ce
And here (so two PRs to the different repos): https://github.com/probot/smee.io/blob/2df8ab37683812fefe01d8a67c8af74ef12db057/server.js#L32
|
I am following this blog to setup smee client https://jenkins.io/blog/2019/01/07/webhook-firewalls/ But it didn’t work
|
Can I know how you configured socketxp to receive webhooks from bitbucket cloud to internal jenkins as I am also facing same 500 error issue while using sme where it is working for github |
Had a poke in the client code and captured some wireshark traces to check what was being sent to jenkins. The problem is that for some reason (not sure why exactly) the content-length is wrong. When I prevent the content length from being added to the request it appears to work. Need to do more testing and can complete a pull request then. |
Ok |
Hi, any update on this issue? please let us know |
Hi Any update on this issue, it would be very helpful if we can get it working for Bitbucket. |
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? |
I am hitting the same problem. I have compared a tcpdump trace of a direct connection from Bitbucket to my Jenkins (works) with the one between smee client to Jenkins. The original POST looks like follows:
The packet coming from the smee client looks like follows:
I have noticed that the spaces behind It seems like the content-length of the packet sent by the smee client is wrong. Is it just copied from the input packet? If I have seen it correctly from the source, the content is interpreted by a JSON slurper and it is re-built before being sent out. If so, I guess, the length should be re-calculated. I am not sure, whether a correct content-length will solve the issue, though. Maybe we also should add the spaces? However, https://jsonformatter.curiousconcept.com/ tells me that the smee client has sent a valid JSON, so Jenkins should be able to cope with it. |
This is probably not a smee client issue, but an issue of smee.io. See probot/smee.io#5. |
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? |
I am getting the same error:
|
Same error here, payload never made it to Jenkins.
|
I have the same issue with bitbucket:
|
I got it working by using the PR from here: #152 manually in the npm code. |
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? |
Yes this is still relevant as at least #152 has not been closed yet. |
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? |
Had same issue while trying to parse gitlab http request into jenkins, #152 fixed it for me. |
Anyone seen this issue?
I'm currently running smee on Centos 7:
smee --url https://smee.io/XXXXXXXXXXXXXX --target https://X.X.X.X/bitbucket-hook/
I logged the call from Bitbucket, and reproduced the POST call using just CURL locally, and it started the job just fine. So it appears Bitbucket is fine and Jenkins is fine. I'm not sure what smee-client doesn't like here.
Any advice?
The text was updated successfully, but these errors were encountered: