Bit Bucket Jenkins Integration.

[satishkamuju]

Hi there,

I am New to both Bit-Bucket and Jenkins.

I have a Jenkins instance running on my local host.

I am trying to integrate this Jenkins instance with my Bit-bucket project using Web Hooks.

I am getting Invalid URL message when i give my Jenkins Instance url. Below is the error screen shot.

Am i missing something here ?

Web-Hook-Error.jpg

Have tried with the IP address also, like http://192.168.1.146:8080/jenkins/job/TestApplication/

Even this did not help me.

Thanks in advance.

Satish.

[Kaz]

localhost is their server for them not yours. Does your Jenkins server have a non-private fixed address? It must not be either 192.168.x.y or 172.16-31.x.y. If you only has a non-fixed dynamically allocated address, consider use of any dynamic DNS service that assigns a fixed host name to your server. Of course, your server must be accessible from internet.

[Kaz]

In addition, if you want to use https connections, the server certificate must not be self-signed but issued officially by a public CA.

[Steffen Opel _Utoolity_]

Kaz' answer is correct and explains the technical background (+1) - while this has often been handled via dynamic DNS indeed, the most common/simple way to expose a local port on your own system to a webservice like Bitbucket (resp. the internet as such) theses days seems to be using secure tunnels to localhost via a service like ngrok - its tagline is to the point.

”I want to expose a local server behind a NAT or firewall to the internet.”

Due to this approach being primarily used for development, ngrok is also the tool of choice in most/all of the Atlassian Connect tutorials, notably also in Getting started with Atlassian Connect for Bitbucket, see step 5 in Create a simple web application to stand in as an add-on:

5. Open a new shell and run the following command: ngrok 3000. This will expose a local port on your machine to the Internet which the add-on can use to communicate with Bitbucket. Leave this running in your shell. You'll see output similar to this:

Security / Convenience

Kaz pointed out that those random host names can be reused some day, thereby posing either a security flaw for the original user and/or denial of service attack for the future user (this problem also exists for the dynamic DNS based approach btw., e.g. when a consuming JVM default TTL is set to never re-resolve DNS names to IP addresses). Conceptually this is a valid concern, and the likelihood of this to happen depends on the randomness of the host name and resp. reuse strategy, if any - the chosen random name format comprises a huge namespace though and should ideally render this likelihood so low as to be negligible, but unfortunately ngrok does not seem to document this, hence we cannot deduce a confident security risk assessment.

Custom ngrok subdomain names

Either way, you can easily work around this and further increase security and convenience for longer running scenarios 'on the side' by using ngrok's custom subdomain names, as also illustrated in Travis Smith' recent blog The secret life of ngrok:

That works reasonably well, but perhaps you want to be able to reuse a hostname or use a specific hostname for the tunnel. As it turns out ngrok supports specifying the subdomain used, giving you a hostname of choice. This does require you to sign up for a ngrok account. It's free, so I'd suggest signing up for ngrok to access this benefit plus the ability to password protect the tunnel, do non-http/https tunnels, and launch multiple tunnels at once. Awesome!

[Kaz]

Thank you for the additional information. If you choose to use such a tunneling service, keep in mind that you should not use any randomly generated host names in webhooks. Randomly generated host names may be assigned to another person someday if you shut down your tunnel. Always use a fixed host name (subdomain).

[Steffen Opel _Utoolity_]

@Kaz Nishimura - Thanks for pointing out this conceptual security issue. I have updated my answer with a risk assessment and options how to deal with this while increasing convenience on the side. I think it's worth noting that a similar and issue exists when using dynamic DNS, no matter the fixed host name: If the DNS name is consumed by a JVM which happens to use the odd (or even ill advised) default TTL to never re-resolve DNS names to IP addresses, you are effectively in the same situation. This non re-resolving JVM DNS behavior has bitten lots of users already, so from my observations, the likelihood of this to happen is considerably larger than the reuse of those ngrok identifiers (provided they handle them correctly) - YMMV of course.

[rrudnicki]

Hi Satish, 

I could see in your screenshot you are using localhost on hooks address. You need to use a valid IP address on Bitbucket side. Also, please check this documentation about webhooks: https://confluence.atlassian.com/bitbucket/tutorial-create-and-trigger-a-webhook-747606432.html

Regards, 
Renato Rudnicki