/home/travis/.rvm/rubies/ruby-2.2.2/bin/ruby -I/home/travis/.rvm/gems/ruby-2.2.2/gems/rspec-core-3.4.2/lib:/home/travis/.rvm/gems/ruby-2.2.2/gems/rspec-support-3.4.1/lib /home/travis/.rvm/gems/ruby-2.2.2/gems/rspec-core-3.4.2/exe/rspec --pattern spec/\*\*\{,/\*/\*\*\}/\*_spec.rb
/home/travis/build/jmoon90/seat_geek/lib/seat_geek.rb:13:in `require': cannot load such file -- seat_geek/taxonomies/tree (LoadError).
The command "bundle exec rake" exited with 1.
I'm setting up Travis CI for my SeatGeek wrapper gem. However, when the CI builds, it bundles correctly, but when it runs the rake tasks, it fails saying it can not load such file.
I'm not sure why that is the case because I make it available in the master file.
It's weird to me that the seat_geek/query/ folders aren't blowing up before that.
What is the problem here?
Travis expects the path to be all lower case. The problem was Github did not update my folder name from Taxonomies/concerts to taxonomies/concerts even after I've made the change and pushed it up.
Github doesn't seem to care if it's uppercase or not. So I had to change the folder name to taxonomiess and push that up. Then after that change it back to taxonomies with lower case.
Related
I've started a rails project using rails new with --webpack=react.
I generated a new controller updated my PostgreSQL password in the database.yml.
Up to this point, everything works fine. At this point all I'm trying to do is get react to render the default hello_react.jsx file that was generated as an example by rails.
When I put <%= javascript_pack_tag 'hello_react' %> in my view and run the server I get the following error:
Webpacker::Manifest::MissingEntryError in Home#index Showing
G:/../../../myGroceryList/app/views/home/index.html.erb where line #1
raised:
Webpacker can't find hello_react.js in
G:/../../../myGroceryList/public/packs/manifest.json. Possible causes:
You want to set webpacker.yml value of compile to true for your
environment unless you are using the webpack -w or the
webpack-dev-server. webpack has not yet re-run to reflect updates. You
have misconfigured Webpacker's config/webpacker.yml file. Your webpack
configuration is not creating a manifest. Your manifest contains: { }
I have pushed the project up to GitHub. Any thought on what is going wrong and how to fix this error?
RESOLVED: Resolution in comments
Jonny B,
I encountered the same issue. I was able to determine that I needed to add '.jsx' to my webpacker.yml.
extensions:
- .js
+ - .jsx
- .sass
- .scss
- .css
I also found that webpacker:compile was not being run on page refresh or when files were changed. I needed to run bundle exec rake assets:precompile (or bundle exec rake webpacker:compile) manually after each change to be able to reload and see the changes.
I am running the application via Apache+Mod_Passenger rather than using rails s (I have too many apps in development at the same time to keep starting and stopping a server on the command line). It seems like this doesn't work well with Webpacker's compile-on-demand functionality. Starting a server with rails s will allow me to hit the app on localhost:3000, but the react app doesn't render correctly. After hitting the page via the Puma server on 3000, I can now see the compiled assets working in my Apache/Passenger instance. So, the on-demand compiling seems to only work properly when running in a server started on the command line (rails s) ...which doesn't render correctly. :-/
The other option (better than running 2 servers) is to compile on the command line using bundle exec rake assets:precompile or bundle exec rake webpacker:compile whenever you make a change. Still a PITA, but at least it works ...for now. If I find a better solution, I'll update the answer.
UPDATE
After a lot of playing around, installing different version of NodeJS, Ruby, rbenv, nvm, etc., I was able to determine that the NODE_ENV wasn't being set for the Apache/Passenger environment. Using Rbenv, I was able to add an .rbenv-vars file in my app root containing:
NODE_ENV=development
RACK_ENV=development
RAILS_ENV=development
Now, Webpacker (and NodeJS) see that I am running in development rather than production, and the compile-on-demand is working.
RESOLUTION: As best I can tell this error fires when your public/packs folder is missing the Manifest file or is missing all together. What was happening in my case was Webpackers compilation step was silently failing and not creating the public/packs folder. I checked in a fix to the webpacker gem for this. You can see that fix and conversation here.
if this is the root cause then you can fix with either of these depending on how you prefer to install node packages
yarn install
or
npm install
I'm receiving an error from a gem file:
~/.rvm/gems/ruby-2.1.2/gems/psd-2.1.2/lib/psd/layer_info/typetool.rb:127:in `to_css': (error is not important)
I want to debug the gem, so I went to that file and added a debugger. It doesn't works. Next I added a raise, just to test. Doesn't works. I went to lunch, and 20 minutes after the debugger line was working. I removed it, run the process again and the debugger was still pausing the script execution, even when the line was not longer on the file.
I run my script with
rails runner myscript.rb
Why is this happening? Is there some kind of cache/opcode that avoids to read the gems source file? I'm not running a webserver, and there is no instance of the application running.
A few things might help you.
How are you opening the code? bundle open? Or are just manually opening the files in the rvm directories? Using bundle open <gem name> will be easiest.
Is spring running? When you modify the gems in your bundle, you will need to issue the command spring stop from the root of your code. This will allow the changes to actually be used.
I bet that spring is causing your issues. If it is, you will need to run spring stop each time that it automatically starts and you'd like to change the code.
I'm deploying a Rails app on Heroku which requires a gem that looks for an executable in PATH. I put my executable inside /vendor/bin and then proceeded as below:
As explained in Heroku docs here, I created a .profile.d directory in the root of my app and then in it, I created a file called path.sh. In path.sh, I set the PATH variable like this:
PATH="$PATH:/app/vendor/bin"
or this
PATH=$PATH:$HOME/vendor/bin
But neither seems to work. The app is deployed successfully but when I run it, I see an application error, and in my logs, I see that this executable could not be found in PATH, thus the application crashed. The script (.profile.d/path.sh) is run for sure though, because in my Heroku logs, I am able to see other commands and the print outs I put in the very same file.
Does anyone know what to do in order to make this work? Thanks in advance.
I was deploying my code in openshift rails but it did not take the assets properly.
It's neither loading the javascripts nor the images.
How to make it work?
The first thing you will want to check is if the assets exist on your application. This script is run before the build.sh script (mentioned next). It attempts to create a symlink for your public/assets folder (here is the reasoning behind this). Even if you had that directory, the rake task would still work; the assets would just be wiped every push.
Your assets should be compiling whenever you push to your git repository. This is taken care of by this script in the Ruby 1.9 cartridge (this is run by the service and you have no control over it). As you can see, it will run bundle exec rake assets:precompile as long as you have a Gemfile (which should be the case for all Rails apps).
With all that being said, the first thing you should do is check your .openshift/action_hooks to make sure you are not running anything that might be overwriting your public/assets directory. You can compare them against the ones here.
The next thing you should do is actually check the directory on your OpenShift host. You can do this by SSHing into your app (instructions are here). Then check your public/assets directory. Note: Some of the output has been shortened with .....
# First we make sure it is a symlink.
> file $OPENSHIFT_REPO_DIR/public/assets
..../app-root/runtime/repo/public/assets: symbolic link to `..../data//assets'
# Then we see if there is anything in it
> ls $OPENSHIFT_REPO_DIR/public/assets
.... (should have a bunch of.js, .css, etc files)
If that directory is empty, maybe there is a problem with compiling the assets. You should pay attention to the output when you git push and see if there is any indication that it is failing (you may want to capture the output using tee like: git push 2>&1 | tee git_push.log). If there are assets in the directory, check your logs by following these steps.
If you're still having problems, swing by our IRC channel and somebody should be able to help in person.
This is my first deployment. I did a cap deploy:setup which worked fine.
Then, when I try to execute cap deploy:update I run into error messages. Something along the lines of
rm: cannot remove `/var/www/app_name/current': Is a directory
Here is my capfile and directory permissions.
http://pastie.org/1189919
In general, what is the best practice as far as deployment user and permissions are concerned? Should I use root or create a different user. If a different user what exact permissions does it need?
Thanks
Did you create the directories within /var/www/app_name, or were they created by capistrano?
Regardless, the issue you have is that /var/www/app_name/current should not be a directory - it should be a symlink to the current release within /var/www/app_name/releases/. The failure is caused when capistrano has finished creating the new release folder within /var/www/app_name/releases/, and is trying to symlink /var/www/app_name/current to it.
You might be able to fix your issues by renaming /var/www/app_name/current (so you have a backup if things go wrong), and creating a symlink from /var/www/app_name/current to the most recent release within /var/www/app_name/releases/, and then doing a cap deploy. (Delete your backup of current if this works).
As far as best practice goes whatever you do, do not use root. Instead, set up a user (or use an existing user) that has only permissions to the required directories (didn't read your scripts closely, but probably just /var/www/app_name.
To deploy a new release you should invoke cap deploy or cap deploy:migrations, not cap deploy:update.
I also have had such errors. A totally normal task of updating source code and restarting the server always seems to have problems at various points of the simple script.
Sometimes it complains that a hash value at github doesn't match some expected value, sometimes it won't update a directory because it already exists, but mostly with it wanting to create things that exist.
Is there no way to force Capistrano and thus the shell commands to just DO IT ? I would at least appreciate it asking me what it should do should it encounter this type of error instead of just failing and rolling back. Especially when it's a simple file operation.
I end up having to delete things manually on the server so that the Capistrano script will run without failing. This is obviously not the way forward.