Rethink deployment autostart script

[lislis]

Read the previous issue here
We ran into issues with our current deployment setup, where our hosting provider switched to a new default Ruby version (2.4.1) while our app is still using 2.3.1.

This caused the deployment hook to fail (rather silently), but the app stayed up on an older version.

After updating the ruby and rails versions of our app and trying to redeploy, the app went down.
This was caused by the autostart script located in config/autostart that is not in version control and only lives on the production server. It contains an absolute path to the ruby binary, so it's bound to break when the next version update happens.

Question is, how can we improve this? Having the autostart script in git would be nice, but we'd need some magic to find the path to the current ruby binary

[til]

I think too that having the autostart in git would be nice. Not sure anymore why it isn't - maybe it was simply to be able to more quickly change and test it initially. But then we should have committed it afterwards. Anyway, feel free to add it to git. Also maybe it is not necessary to specify the full path to ruby (or actually to the bundle executable, as it is currently). Or it is necessary to load something first, and afterwards one can call the bundle executable without full path. Here are the general docs https://wiki.uberspace.de/system:daemontools and here are some useful examples for start scripts. https://wiki.uberspace.de/system:collection_of_run_scripts Many examples do this: # Include the user-specific profile . $HOME/.bash_profile Do you want to try that? And then instead of /package/host/localhost/ruby-2.4.1/bin/bundle exec thin -a 127.0.0.1 -p 34567 start just bundle exec thin -a 127.0.0.1 -p 34567 start ?

[lislis]

As a comment, the same thing happened this week when uberspace updated to Ruby 2.5.1 and the app was running 2.4.3.
It's all updated now but I should really get this done