search

probot / friction

a place to talk about any friction experienced using Probot.
8 stars 9 forks source link

localtunnel sucks #5

Closed hiimbex closed 6 years ago

hiimbex commented 7 years ago

localtunnel is very inconsistent and frustrating to work with. It would be great to do some research on (preferably free) alternative services.

elliotblackburn commented 7 years ago

When I started working with probot locally I didn't even bother with localtunnel. I went straight for ngrok, it has a free tier which does mean each time you bring it up you'll be given a new subdomain but you can leave it running in the background during a dev session and forget about it happily. https://ngrok.com/.

It's not too painful even though it doesn't have a node api or anything.

anglinb commented 7 years ago

@BlueHatbRit Ya I end up using ngrok and localtunnel like 50% each of the time b/c as you said 👇

each time you bring it up you'll be given a new subdomain

which can be kinda annoying b/c you have to go back and update your GitHub App settings.

anglinb commented 7 years ago

Took a look into ngrok and it looks like it's open source: inconshreveable/ngrok To me there are 2 possible solutions:

  1. Wait for a GitHub App settings update endpoint and use that to change the endpoint when ngrok changes
  2. Run a patched ngrokd server

Spit balling about option 2: We could patch ngrok to use GitHub's OAuth provider to assign a subdomain that would simply be your GitHub handle. Ex: anglinb.probot-ngrok.com or something to that affect. To keep the costs low, we could also limit incoming connections to GitHub's IP range. Would only have to find someone to host it *cough* GitHub *cough* 😉

hakusaro commented 6 years ago

I'd like to add another +1 here too. It's also not documented anywhere I can see what exactly it does. I turned it off too, and that seemed to have no affect on a deployed app. I'm assuming this is just for testing webhooks, now that I ramble more about it, but I don't know.

Currently, localtunnel produces this obscure error on the app I was working on:

tunnel server offline: connect ECONNREFUSED 138.197.63.247:443, retry 1s
tunnel server offline: connect ECONNREFUSED 138.197.63.247:443, retry 1s
tunnel server offline: connect ECONNREFUSED 138.197.63.247:443, retry 1s
tunnel server offline: connect ECONNREFUSED 138.197.63.247:443, retry 1s
tunnel server offline: connect ECONNREFUSED 138.197.63.247:443, retry 1s

I know that was resolved in https://github.com/probot/probot/commit/b5d05b3913feb50bb03defbc52300bd14f19f55b but it's still a frustrating thing to smash into. I had to do about an hour of research trying to get probot to work for what I wanted to do (which was unfortunate) because of this and another issue.

JasonEtco commented 6 years ago

@hakusaro we use localtunel to tell expose your local app server to the internet so that GitHub knows where to send payloads (since it doesn't know what localhost means). We're working on a replacement for using localtunnel right now over in probot/webhooks so stay tuned, but its not quite ready yet.

As for that error in particular, it looks like localtunnel itself is down which is unfortunate. It's a little unstable which is why we've started building our own homegrown replacement.

hakusaro commented 6 years ago

Right, that's kinda what I had figured only after the fact (once you deploy probot and set a webhook url it becomes extremely obvious). Is there any reason why this should get deployed as on in standard practice? Could it somehow be turned off by default when doing a deployment, or would all of the deployment scripts have to be updated to reflect that?

JasonEtco commented 6 years ago

I'm not sure I understand your question @hakusaro, so I'll try my best. If you're wondering how localtunnel works once its been deployed, it is automatically disabled based on the NODE_ENV environment variable (which Heroku ~and Now~ set by default). See here:

https://github.com/probot/probot/blob/6aa3a2f7b2d4567c7f7d806538acb6d1fa9b5b83/bin/probot-run.js#L13

It is used only for local development and disable-able with the DISABLE_TUNNEL environment variable, but like I mentioned we're working on a better replacement for it.

GitHub
probot/probot
probot - 🤖 A framework for building GitHub Apps to automate and improve your workflow
hakusaro commented 6 years ago

@JasonEtco hmm, I don't seem to see that behavior you're describing with Zeit Now. I suppose it's possible that Heroku actually does work (this is my first time with Zeit Now and not Heroku).

I deployed with:

now -e APP_ID=[app id] -e WEBHOOK_SECRET=[secret] -e PRIVATE_KEY="$(cat ~/Downloads/oneline.pem)" -p -f

Here is what the logs look like:

12/08 12:56 AM (1m)
npm install
12/08 12:56 AM (1m)
✓ Using "package-lock.json"
⧗ Installing 6 main dependencies…
12/08 12:57 AM (54s)
✓ Installed 789 modules [20s]
12/08 12:57 AM (54s)
npm start
12/08 12:57 AM (51s)

> update-docs@1.0.0 start /home/nowuser/src
> probot run ./index.js
12/08 12:57 AM (46s)

tunnel server offline: connect ECONNREFUSED 138.197.63.247:443, retry 1s
12/08 12:57 AM (45s)
tunnel server offline: connect ECONNREFUSED 138.197.63.247:443, retry 1s
12/08 12:57 AM (44s)
tunnel server offline: connect ECONNREFUSED 138.197.63.247:443, retry 1s
12/08 12:57 AM (43s)
tunnel server offline: connect ECONNREFUSED 138.197.63.247:443, retry 1s
12/08 12:57 AM (42s)
tunnel server offline: connect ECONNREFUSED 138.197.63.247:443, retry 1s

So maybe this is another problem with Zeit Now?

Edit: More context: I verified that the line of code that checks the environment variable is present in the node_modules version of probot deployed too.

JasonEtco commented 6 years ago

My apologies @hakusaro , after a quick Google it looks like Now does not in fact set NODE_ENV to production by default. I guess you'll want to set that -e NODE_ENV yourself.

bkeepers commented 6 years ago

localtunnel is gone. Long live smee! https://github.com/probot/probot/releases/tag/v5.0.0

GitHub
probot/probot
probot - 🤖 A framework for building GitHub Apps to automate and improve your workflow