-
-
Notifications
You must be signed in to change notification settings - Fork 114
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
Refactor start command to use Rackup instead of Puma #875
Conversation
@ayushn21 I spent a little time with this and it feels pretty solid! Excited to see the progress. |
I've disabled live reload when using servers other than Puma. It's causing a few issues. Probably a can we can kick further down the road I think. |
Hey @jaredcwhite could you stress test this PR a bit please? I'm too close to it to test it properly 🙈 |
I think it's looking really great @ayushn21. 🙌 I have a couple of small fixes on hand regarding when the frontend process isn't running (it crashes on Ctrl+C due to missing PID) and just some process messaging on startup. Mind if I push up and we can do a final review, or do you want to step through it ahead of time? |
I took the liberty of pushing up one fix, as there was a bug where the watcher in SSR mode wasn't returning from a method before setting up an INT trap, causing automated tests to hang and run indefinitely! 😬 |
Go ahead and push it :).
Awesome thanks! I was stumped by that when I was working on this but was too tired to figure it out at the time so I kicked the can down the road. Thanks for fixing it! |
@ayushn21 All right, I pushed up a couple of things…binding to |
This is a 🙋 feature or enhancement.
Summary
This PR refactors the
start
command to useRackup
instead of Puma. This way we can run Bridgetown with any Rack compliant server and aren't restricted to Puma.Rackup will automatically detect from the
Gemfile
and start it. Our out-of-the-box Puma setup still works as is.To do:
options[:using_puma]
.start
file and use info from Rackup.More details
I had to refactor the way we start the Bridgetown build and aux processes to make it work with this setup. We're now forking a process which runs the build in the background. That in turn starts the aux processes like the frontend watcher. As such I now track PIDs in files so we can kill the processes we start despite stuff happening in different processes.
Context
Fixed #860