i'm trying to trigger builds on jenkins when ever a pull request is merged, and trying to add the webhook, which is throwing me the below error.
payload url: http://localhost:8080/job/hook-test/
error: "We couldn’t deliver this payload: Couldn't connect to server "
The URL for the webhook is localhost. GitHub is trying call the webhook on itself.
You need to deploy Jenkins in a publicly accesible URL. It won't work with a local Jenkins install in your PC.
localhost refers to the address of the current machine. When you type localhost in the browser and you access Jenkins, that works because you have Jenkins installed and running in your PC. Access localhost from a different machine and you won't be able to access Jenkins. When you tell github to send the webhook to localhost it will not try to send it to your machine, instead, it will send the webhook to the same machine in which github server is running, and that machine doesn't have Jenkins installed.
The problem here is localhost means something different for you and for github.
To solve this problem, you'll either need to install Jenkins in a public server accesible from internet (so that github can send the webhooks) or use some online service which provides hosted Jenkins servers.
You could also just get a domain and configure it to point to your PC. You would probably need to do some networking configuration but once it's done you (and github) will be able to access your jenkins via some-domain.example.io instead of localhost. Be careful, you would be making your (I asume personal) PC accesible from the internet, and that has security risks.
If you can afford it I recommend using a server in the cloud to run this.
Many cloud platforms even provide a quite long free trial period (I know Amazon and Google Cloud do).
Related
we have a TFS 2018 running inside our Intranet and want to deploy to a remote machine outside of our intranet. The TFS is not visible from the outside (behind Firewall and does not have its own IP)
So we came up with this solution, that might work:
Set up a VPN connection between the target machine and our intranet
Create an Azure Pipeline Agent on the target machine that uses a private access token to communicate to the TFS
Is there an easier solution to this, which doesn't require a VPN connection?
We thought we could deploy to a web share from TFS and then trigger the Azure Pipeline Agent on the target machine, to start the deployment. But from the documentation of Microsoft it seems as if the Agent has to have direct access to the TFS trough HTTPS and only "listens" to jobs in the TFS queue.
That means that the only other solution to a VPN connection from the target machine would be, to make our TFS accessible from the internet trough HTTPS, right?
Unfortunately, until now we haven't found a lot of documentation on "best practices" for this use case. That's why I decided to share it here. Thanks!
According to Configuring the Artifactory Service Endpoint, an artifactory instance as service endpoint need to be configured. One of the parameter is the server URL to the artifactory. What if the server URL is a local intranet, will the URL be considered valid ? I am having error with the URL I am providing (Local intranet). The error is:
"Failed to query service connection.....Error Message:'An error
occurred while sending the request'"
What if the server URL is a local intranet, will the URL be
considered valid ?
While the server URL you used here is a local internet, which means our azure image(Hosted agent) could not get communicate with it from public internet. That's why the error message told you failed to send request to server.
So, here the best way is you need configure one self agent in that local machine.
BUT, if Hosted agent is one preferred choice in pipeline execution. I'm afraid you have to configure your artifactory instance to make it accessible from the internet, just like the URL in the blog you shared above. Because our Hosted agent actually is Azure VM which hosted in cloud.
We host a website in our company.
A certificate was issued to www.ourdomainname.com from the company IT department.
Now we want to move the website to azure and install the certificate there.
I already exported the certificate with private key exported set to true from the server.
1.) What will happen when the certificate is installed on azure when it is also installed on our company server?
2.) What will happen when the website on our server is stopped in the server and the certificate is then imported to the azure website?
3.) How can I guarantee a soft transition time without any break?
The aim is:
Website on the company server going to be deleted and the website on azure is used instead.
What will happen when the certificate is installed on azure when it is also installed on our company server?
web site will be available via SSL in Azure too.
What will happen when the website on our server is stopped in the server and the certificate is then imported to the azure website?
web site on your server will be inaccessble.
How can I guarantee a soft transition time without any break?
it is more about DNS management. There is no much work with SSL. You just install SSL on both internal and Azure servers, so clients can access both. Test if web site on Azure works the same way as on your internal server. Then point all clients (via DNS) to a web site on Azure. When all clients move and there are no references to internal server, you can safely shutdown it.
The SSL Certificate which was exported from the current server has to be imported in Azure. The format of the certificate has to be PFX.
Now, in the DNS Management , you need to edit the A record for the URL and point it to the IP address of Azure. This will make sure that any request made will be handled by Azure .
I'm trying to deploy a service fabric application to an unsecure Azure Service Fabric cluster. When I open the publish window in VS 2017 I get the following. If my cluster is unsecure, shouldn't I be able to publish it w/o configuring the cert?
I tried a publish anyways and I got:
Try accessing the server via powershell to maybe get a better error. Usually, errors like this are caused by firewalls blocking the port 19000.
Good evening, just saw that Facebook released his messenger bot toolkit and i immediately jumped right into it to learn more about it and maybe try to do my own.
My problem is that i don't have a https website running and it requires a https valid url. I tried to use my local web-server that has a certificate but it doesn't work.
My question is if this is possible to be done using a localhost url at all.
Thank you in advance
Actually this is possible with localhost. Use ngrok. It allows you to open localhost to the public web, over http or https. This should only be used for testing however.
If you want to test webhooks on your local environment, I would try ultrahook.com, you can get an API Key for free and the tool creates a tunnel from a public URL to your computer. This is from their FAQs page:
You download and run the UltraHook client on your computer. It
connects to UltraHook servers in the cloud and creates a tunnel from a
public endpoint on our servers to your computer. Any HTTP POST
requests sent to the public end point will be sent through the tunnel
an delivered to a private endpoint accessible from your computer.
I have used it to test webhooks from different providers (like payment gateways). In your computer, you can run something like:
ultrahook <subdomain> http://localhost:8000/webhook/
and then configure the webhook URL in your external service to something like <subdomain>.ultrahook.com
My question is if this is possible to be done using a localhost url at all.
No, of course it isn’t – because what such a “callback” actually means, is that Facebook makes a request to your server – and that is hardly possible with localhost.
A valid SSL certificate for your website is easy to get for free these days, via LetsEncrypt. And even if that is not available on your server, there’s still StartSSL, that provide basic certificates for free. All you need is a server you can install them on, or upload them to, or whatever mechanism your hoster provides for it. (And if they don’t provide any, then it might be time to switch.)