-
-
Notifications
You must be signed in to change notification settings - Fork 10k
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
Jekyll 2.5.3 does not work on Heroku #3907
Comments
The host is 127.0.0.1 in 2.5.3, maybe use |
Good catch, i'll give that a try. |
Ok, let me know if you're still having troubles. We don't really recommend using the built-in WEBrick server for production environments, though, so I'd recommend using something more robust if you have the time. |
I can confirm, https://github.com/schneems/schneems/blob/master/Procfile I'll check internally and see if there's some reason it works with one and not the other. Did this default change in jekyll sometime? |
Does Heroku give off a $HOST like it does a $PORT? If it does we can probably detect both easily. |
Doesn't look like it:
|
We might be able to work something out for people who want to use Heroku, you guys do support Docker it looks like (if I am right?) our Docker images already shiv 0.0.0.0 as the address, I'll work out a how-to so people can use our Docker images to get onto Heroku quickly. |
Or I might just build a jekyll/heroku image. |
Yeah, this changed between 2.4.0 and 2.5.3. |
I got word from our runtime team it looks like 127.0.0.1 is only for internal connections, cannot be used for external communication. That's why it works on local development, but won't work when you deploy it. Looks like it was changed here #3053. While I agree you shouldn't be running a "production" server on webrick, I would argue that it should just work (tm) out of the box for people playing around. I'm actually able to get a good amount of throughput with webrick and certainly good enough for the traffic I get, maybe a few thousand hits a day when I release an article. It looks like rails binds to "localhost" https://github.com/rails/rails/blob/565582c0f5f1fe17357df67978e2f684db305bf9/railties/lib/rails/commands/server.rb#L27 instead of a specific ip, and this works on Heroku out of the box, and would avoid that chromium error. Would you take a PR to change this in jekyll? |
Your argument that "it should just work" is invalid with the reasons you justified later in your argument. It won't just work. |
A) I know basically nothing about DNS. Up until today I thought 127.0.0.1 and 0.0.0.0 and localhost were all synonymous. B) Someone at Heroku corrected me that "localhost" should not work since localhost would map back to the internal ip
My argument is that
It is connecting to |
Rails server works out of the box because Heroku gives it special treatment, it not only detects Rails, it has a default proc file it will supply and it used to also shiv some defaults for you that made it work better on Heroku. So I would argue that if Heroku does that for Rails it needs to do that for Jekyll instead of us doing it for Heroku because once we treat Heroku special what about the other providers? |
What I am saying is, it's probably Heroku that is making that magic happen. Not Rails. |
I'll digress that to @parkr but I personally see no problem with us doing something like that since we do have the notion of JEKYLL_ENV now in 3.0.0 (I don't remember if that landed in 2.5) |
I see the buildpack as a hack that needs to know far too much about individual libraries to just get you running. For most cases we want to do the bare minimum. We want to minimize "magic" so that you get what you expect. This is why we don't inject anything into Rails 4.1+ apps, although we do write a default Procfile for you. I've spent a bunch of time working with Rails to make it easier to run on any platform not just Heroku. It is in my best interests if I think having some docs on Heroku around jekyll could be a good start. Right now it's really easy for me to use jekyll on heroku, all I need is a procfile and i'm good to go. If it starts getting more complicated in future versions, it would help to have docs. I'll bring up docs in planning. |
Love the idea of making it as easy as a procfile. I imagine localhost is fine. Not sure why we went from localhost to anything else. Maybe localhost on local machines wasn't fit for outside use? I can see 0.0.0.0 being good for JEKYLL_ENV=prod and 127.0.0.1 being good for JEKYLL_ENV=dev. Thanks, schneems! |
Took advice from jekyll/jekyll#3907 Maybe this works.
Not getting any error messages or whatnot, it's just not binding to a port
I bumped it back down to jekyll
2.4.0
and it worksStill no indication of why one does and the other doesn't. Any ideas?
The text was updated successfully, but these errors were encountered: