In my Rails (Release 6) web application I'll use a bash script to do some action. The app will call the script in a controller with a fragment inside backticks.
def action
...
`#{custom_script_dir}/my_script.sh`
...
render ...
end
Which directory I should place my script into? Is there a standard place for such custom extra shell scripts?
There isn't a strong convention for this.
Maybe you can use the bin folder. Look at this answer as an example:
What's inside my rails ./bin directory?
...
I personally do put some stuffs[sic] in the bin folder. Scripts to connect
to remote servers, or ruby scripts I need but that I don't want to run
as rake tasks since they're more general than my application.
...
However, it is up to you to decide which folder is the best for you. Also, feel free to create as many folders as you want in your Rails application if it makes sense for your project.
Related
I have a rails engine that exposes a command called myengine create. That command generates a full Rails application with myengine already integrated into it. The command calls rails new ... to generate the app. Everything works fine as long as I execute this command outside of the engine folder. However, if I execute it inside the engine folder, it breaks because it runs the bin/rails command inside the engine, instead of the regular rails command that is installed on the system. The bin/rails inside the engine folder is configured to work with engines so it doesn't have a rails new command.
I'm trying to write automated tests that run the myengine create command from within the engine to validate the output. If I'm anywhere inside the engine directory though, calling rails new fails.
I've tried specifying the exact rails command like "/home/me/.rvm/gems/ruby-2.3.1/bin/rails new ...", but this doesn't work.
The only workaround I've been able to come up with is to build the application outside of the engine folder by using Dir.chdir or Thor's inside method. I can test against it there, or even move the newly generated app folder back into my spec/ folder. It works, but it feels sloppy. There must be some way to generate a new from inside an engine.
If anyone else runs into this, I ended up enhancing my command to rename bin/rails to a temporary new name before it tried to run rails new. Then the command renamed it back once rails new completed.
I have a repo with the folder structure as such
root_of_repo
-app
-some_gem
-some_gem
Within the app folder is where my Rails app lives. I would like for beanstalk to deploy the rails app from within this folder. However, it keeps trying to deploy the Rails app from the root. How would I tell beanstalk to first navigate into the app folder then continue running the necessary rails actions (bundle, rails s, etc).
beanstalk is very sensitive to structure as its deployment process is mostly a bunch of shell scripts wrapped together. therefore it won't bend to your new structure.
a couple of options here:
1. adapt to the standard structure, which is also recommended by rails. don't nest "app" folders.
2. create a pre-deploy script (.ebextension) that copies your folder to the right place.
This is a simple question, but I haven't been able to find an exact answer to it anywhere.
I have a standalone Python script which I am using in my Rails app. What is the appropriate folder I should save it in according to convention, so that I can push it to production (currently running it from my computer's desktop)? I think the answer is lib/assets but I want to make sure.
I don't think there is an exact answer for this question.
If it is a ruby script, it is usually placed in lib or bin.
From the rails folder descriptions in Getting Started with Rails guide:
bin/ Contains the rails script that starts your app and can contain
other scripts you use to setup, deploy or run your application.
lib/ Extended modules for your application.
You could put it in lib/assets folder as it reflects your understanding that it is an external asset used in the system.
I'm converting my RoR app to use capistrano v3. I have a number of configuration file that are generated by ERB. Most of these files, like like /etc/logrotate.d/app_name, are referenced external to my app. So I like the idea of linking them to my shared/config directory. Capistrano supports managing linked files via the linked_files array. So far so good. But, the files to be linked don't technically exist until I run ERB. And capistrano runs :deploy:check:linked_files as the first step of :starting, at which point the files don't exist and the check fails.
So my question is, what's a really good way to handle this? Do I check in empty config files in my config directory, let capistrano link them to shared, and then overwrite them via ERB at a later stage? That doesn't feel good. I can't generate them before the :starting task because on an initial deploy the source tree isn't there yet. Any suggestions?
I have seen examples where it is put in the lib folder, and another example in the app folder. Is there standard place where it should be put for Rails 2.3.8 and Rails 3 convention?
Scripts have to go into the /scripts folder. Of course there's almost always the confusion as to how to differentiate a script from a regular ruby file that is 'required' by a controller/model. If your script is required to start/sustain your application, then yes its a script. Or else if its a ruby file that is need at times or just for some cases wherein it complements the model/controller, you're better off putting it in the /lib folder.
I usually don't have runner scripts, but instead directly call some method that exists either on a model or in something in lib. For example, my Rails cronjobs typically look like this:
/path_to_app/scripts/runner -e production "SomeModule.perform_task"
I think this is cleaner.
I wrote a script on one one occasion, though, and in that case, I just put it in the lib directory:
/path_to_app/scripts/runner -e production /path_to_app/lib/perform_task.rb"