I am in the process of deploying my Rails application with Passenger and when I run this command to get my application ready and set for production I get this yarn message but no further actions are run.
bundle exec rake assets:precompile db:migrate RAILS_ENV=production
Output from that command:
yarn install v1.3.2
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
info Lockfile not saved, no dependencies.
Done in 0.04s.
When this is finished running I hop into the Rails console and run Rails.env and the result is development. I have removed and re-installed Yarn but that is no luck. There are no Yarn dependencies so I am confused as to why I need it in the first place. If I run the bundle exec command without Yarn installed I get this message:
Yarn executable was not detected in the system.
Download Yarn at https://yarnpkg.com/en/docs/install
Does anybody know how to by-pass this or set this to production mode without having Yarn installed?
I have also tried running:
RAILS_ENV=production rake assets:precompile
But get this rather large input:
/var/www/isharelessons/code/vendor/bundle/ruby/2.3.0/gems/rake-12.3.0/lib/rake/file_utils.rb:10: warning: already initialized constant FileUtils::RUBY
/var/lib/gems/2.3.0/gems/rake-12.3.0/lib/rake/file_utils.rb:10: warning: previous definition of RUBY was here
/var/www/isharelessons/code/vendor/bundle/ruby/2.3.0/gems/rake-12.3.0/lib/rake/file_utils.rb:109: warning: already initialized constant FileUtils::LN_SUPPORTED
/var/lib/gems/2.3.0/gems/rake-12.3.0/lib/rake/file_utils.rb:109: warning: previous definition of LN_SUPPORTED was here
/var/www/isharelessons/code/vendor/bundle/ruby/2.3.0/gems/rake-12.3.0/lib/rake/file_utils_ext.rb:17: warning: already initialized constant Rake::FileUtilsExt::DEFAULT
/var/lib/gems/2.3.0/gems/rake-12.3.0/lib/rake/file_utils_ext.rb:17: warning: previous definition of DEFAULT was here
WARNING: Possible conflict with Rake extension: String#ext already exists
WARNING: Possible conflict with Rake extension: String#pathmap already exists
[....]
When you run a command like
bundle exec rake assets:precompile db:migrate RAILS_ENV=production
It will use the production environment when executing those commands, but it doesn't put you in the environment beyond the duration of that single rake command. If you then run
$ rails c
2.4.2 :001 > Rails.env
=> "development"
It's showing development, because RAILS_ENV is empty, and when empty, the default environment is development.
When you specify an environment on the command line at the end of a rake command, it doesn't change the shell's environment; it's just an argument to the rake command, and does not persist in any way.
Similarly, when you prefix a command with the environment, like
RAILS_ENV=production rake assets:precompile
It does not persist beyond that single command. It's a temporary variable assignment. That does change the shell variable, but only for the duration of that command line, and it also does not change the environment for future commands.
If you want to set the environment for your shell session, so that it affects all future commands (until you log out or start a new shell), then you have to export the variable:
$ export RAILS_ENV=production
$ rails c
2.4.2 :001 > Rails.env
=> "production"
Related
I have an image asset in app/assets/images which I am trying to compile before deploying in production as per asset pipeline guide.
Upon trying to execute:
RAILS_ENV=production rails assets:precompile
I get the following error:
rails aborted!
Errno::ENOENT: No such file or directory - C:/../bin/yarn --version
Tasks: TOP => assets:precompile => yarn:install
(See full trace by running task with --trace)
The above error also happens when I run
rails yarn:install
Checking yarn version
$ yarn
yarn install v1.22.5
[1/4] Resolving packages...
success Already up-to-date.
Done in 0.80s.
I have installed webpacker 5.2. I tried to check the bin/yarn file but did not find any problem. Any ideas?
I have similar problem, and this deals because using rails 6.1 that has this issue, they have pushed merge to branch, but if you still has problem
temporary solution that I did
create one file /bin/yarn
if you using linux just put content as below
#!/bin/bash
exit 0
and make sure it executable, by running chmod 755 /bin/yarn
now you can run precompile command
I have a previously deployed Ruby on Rails API that I wanted to add some additional seed data to.
I am getting the following error when I deploy from either the Heroku CLI or from the web interface:
-----> Ruby app detected
-----> Installing bundler 2.0.2
-----> Removing BUNDLED WITH version in the Gemfile.lock
-----> Compiling Ruby/Rails
-----> Using Ruby version: ruby-2.6.5
-----> Installing dependencies using bundler 2.0.2
Running: bundle install --without development:test --path vendor/bundle --binstubs vendor/bundle/bin -j4 --deployment
bash: /tmp/build_9062c7d5995d7f7c573d9509eb8f19d5/bin/bundle: cannot execute binary file: Exec format error
Bundler Output: bash: /tmp/build_9062c7d5995d7f7c573d9509eb8f19d5/bin/bundle: cannot execute binary file: Exec format error
!
! Failed to install gems via Bundler.
!
! Push rejected, failed to compile Ruby app.
! Push failed
I am not sure what the issue is. I have tried:
Deploying to a brand new Heroku application
Adding a Procfile
Adding a Ruby build pack
Resolving some outstanding security warnings from Github by running Bundle update locally and getting the new gemfile into my repo, prior to this there were no new Gem changes
None of these has changed the error I am getting.
If I clone the repo from github into a new folder on my Macbook I am able to get it up and running locally.
I have the following on my Macbook:
Ruby Version 2.6.5p114
Rails Version 6.0.3.2
Google does not seem to be turning up much, aside from some references to CPU architecture which I assume I have no control of in the Heroku environment.
My feeling is that it is related to bash being unable to execute bin/bundle but I've no idea why or how to resolve.
I vaguely recall having issues previously on this app, in that I was not able to run heroku run rake commands, possibly getting a similar error message, but to resolve I think I was able to simply run heroku run bin/rake
I believe the original rails new command was run on Windows 10 WSL environment in case that is relevant.
EDIT: I'm able to recreate a similar issue with rake, but the fix for rake does not work for bundle and I'm not even sure if it would help with the deployment issue.
➜ appbackend git:(master) heroku run rake
Running rake on ⬢ heroku-name-40049... up, run.8396 (Hobby)
bash: /app/bin/bundle: cannot execute binary file: Exec format error
➜ appbackend git:(master) heroku run bin/rake
Running bin/rake on ⬢ heroku-name-40049... up, run.5201 (Hobby)
Abort testing: Your Rails environment is running in production mode!
➜ appbackend git:(master)
➜ appbackend git:(master) heroku run bundle install
Running bundle install on ⬢ heroku-name-40049... up, run.7746 (Hobby)
bash: /app/bin/bundle: cannot execute binary file: Exec format error
➜ appbackend git:(master) heroku run bin/bundle install
Running bin/bundle install on ⬢ heroku-name-40049... up, run.4632 (Hobby)
bash: bin/bundle: cannot execute binary file: Exec format error
Turns out it was exactly as the error message stated Exec format error.
The bundle file in the bin directory was not the right format. Not sure how I managed to deploy in the first place (the history of this file has only 2 version in the repo, the first commit, and now the fix).
I was able to resolve by overwriting the bundle file from a different working rails install. Appreciated the help provided.
I have this script that should be running from the /~ directory:
#!/bin/bash
APP=/root/apps/monitoring
cd $APP
git pull
rake assets:precompile RAILS_ENV=production
touch $APP/tmp/restart.txt
As you can see, it pulls new commits and updates the assets and restarts Apache. The problem is when it runs the line rake assets:precompile RAILS_ENV=production, It says:
Could not find proper version of rake (12.1.0) in any of the sources
Run `bundle install` to install missing gems.
Which is strange because I am supposed to be inside the app's folder (/root/apps/monitoring) when this command is executed. What I am doing wrong?
You may need to load rvm in the script (https://rvm.io/workflow/scripting) and may be select proper ruby/gemset.
Also you can consider using wrapper for bundle created with rvm wrapper
Please try
#!/bin/bash
APP=/root/apps/monitoring
cd $APP
git pull
bundle exec rake assets:precompile RAILS_ENV=production
touch $APP/tmp/restart.txt
With bundle exec it should work.
I run rake tasks using bash script wrappers. The trick is to use the source command to load in the rvm environment after the task is started
example.sh
#!/bin/bash
# change the directory
cd /home/ubuntu/GSeries
# load rvm ruby
source /home/ubuntu/.rvm/environments/ruby-2.4.2#mygemset
bundle exec rake db:prune_logs RAILS_ENV="production" &>> /home/ubuntu/GSeries/log/prune_logs.log
Rails C and Rails S not working when in the correct directory.
have tried:
$ bundle exec rake rails:update:bin
this returns the following error:
bundler: command not found: rails:update:bin
Install missing gem executables with `bundle install`
I have ran:
Bundle Install
this still returns the same error
Have changed directories (higher and lower), repeated steps and attempted commends for same result.
I was running rails server, when i stopped the server and tried to restart server, the error appeared, so I'm thinking this has something to do with a physical location change (potentially the bin file), which is consistent as when I try and run a bin/rails command, i'm receiving an error of:
bundler: command not found: rails:update:bin
Install missing gem executables with `bundle install`
I have tried to rake the bin folder as below:
rake rails:update:bin
however I am receiving this error:
rake aborted!
Don't know how to build task 'rails:update:bin' (see --tasks)
Finally, I have checked the physical location and there is a .bin file, however this folder is empty and it's not in a .gitignore directory.
Ancillary information
Rails version: 5.1.4
ruby version: 2.3.4
Server: heroku
OS. Ubuntu 16.04 (via virtualbox).
I have not upgraded rails, this is a fresh install
I am at a loss.
rails update:bin or rake update:bin These are the right ways that execute a rake task.
I learned Rails using just the rake command like rake db:migrate; however, I read that I should be using the bundle exec rake ... instead of just plain rake. Now I'm confused about which to use.
Should I be using bundle exec rake instead of just plain rake or is it just a preference thing? Any insight would be much appreciated! Thanks!
bundle exec executes a command in the context of your bundle.
That means it uses the gems specified in your Gemfile. Much of the time, running bundle exec rake foo has the same results as if you just ran rake foo, especially if you have the same gems installed systemwide as in your Gemfile. However, some applications may specify different versions of gems than the ones you have installed systemwide, and may want those exact gems and versions to be able to run correctly. If you just run without bundle exec, you may get some weird errors.
Using bundle exec guarantees that the program is run with the environment specified in the gemfile, which hopefully means it is the environment that the creators of the program want it to be run in, which hopefully means it should run correctly no matter what weird setup you have on your computer.
It basically standardizes the environment under which the program is run. This helps avoid version hell and makes life much easier.
See http://bundler.io/v1.3/man/bundle-exec.1.html for more info.
$ bundle exec rake db:migrate
Uses the version of rake specified in the Gemfile to execute the rake task db:migrate.
But there is no rake gem specified in the Gemfile!
Yes, but a rake gem was installed as a dependency of some other gem--look in Gemfile.lock. So the rule must be: Uses the version of rake specified in Gemfile.lock.
But Gemfile.lock doesn't specify a specific version--it specifies a version greater than x.y!
Then the rule must be: Uses the version of rake that was installed in the current gemset.
$ rake db:migrate
Normally, when you issue a command on the command line, e.g. rake, your system searches for the command in the list of directories specified in your PATH environment variable. The first directory that contains the command is the version of the command that is used. To see which directory that is, you can do:
$ which rake
So if you execute,
$ rake db:migrate
that may use a different rake gem than the one you installed with bundle install. But, even if your system finds the same rake version as bundle exec, any gems required by the rake source code will be searched for in places outside your project's gemset. Therefore, there are many ways that just:
$ rake db:migrate
can screw things up.
According to the Ruby on Rails Tutorial Book(free online), section 3.6, if you are using rvm 1.11.x+ then you do not need to preface commands with bundle exec.
running any exacutable without bundle exec will have Rubygems fetching the latest version of the gem installed in your system.
By adding the bundle exec prefix instead will have the executable running in the context of your Gemfile.lock, which means that will be run using the version defined in the gem file.