I assume this would be the same as enabling the asset pipeline in a project that was created --skip-sprockets - I could be mistaken.
I'm trying to run rake assets:precompile to test, and right now, since I've already added require 'sprockets/railtie' to my config/application.rb - it finds the task at least - but it says:
no such table: app_configs
Update: I've discovered that this error is coming from a model in our application called AppConfig - so I'm looking into that part. I don't know why it only happens when running this rake task...
Update: It seems that this particular rake task is assuming I'm in the production environment, even though I'm in my development environment. Other rake tasks don't seem to have this problem... ? It shows that the task it's actually running is: /home/.../bin/rake assets:precompile:all RAILS_ENV=production RAILS_GROUP=assets
So it makes sense that it's not finding the table, because it's looking in the wrong database (probably one that doesn't even exist). But how is it determining (incorrectly) that it's in a production environment?
As it turns out:
I did have the asset pipeline setup almost correctly: all you have to do is run rake rails:update to make sure your project files are all updated to be compatible with your current Rails gem (3.1.x). It will warn you when it's going to overwrite files and you can view the changes and edit the file yourself (there's no merge option unfortunately). These changes include several configuration directives specific to the asset pipeline (in the config directory).
One special problem I encountered is addressed by this post: How to build task 'assets:precompile'
- (I was not requiring rails/all, so I had to add the sprockets require)
After doing all this is when I ran into the production environment problem. The assets:precompile task intentionally uses the production environment so that it produces production-ready assets; if you use the development environment it compiles assets according to the configuration in environments/development.rb which generally doesn't include digest urls. So that's intentional - the problem then is that when it initializes the production environment, it's trying to access a database that doesn't exist in the dev environment. The way to get around that (for testing purposes) is to add this to your config/application.rb file:
config.assets.initialize_on_precompile = false
This prevents it from initializing the app and voila, no more initialization errors during asset pre-compilation :) However: There's no reason to leave this set to false, unless you intend to precompie all your assets in a non-production environment for some reason (like Heroku does) rather than allowing Capistrano or some other deployment tool to compile them in production when deploying the app. initialize_on_precompile actually lets you use models and other application resources in your asset templates, which can be a useful feature.
Another helpful post: Upgrading from Rails 3 to Rails 3.1
Related
I am using a Capistrano deployment workflow for a Magento project.
On deploy Capistrano builds this Magento project on the server using https://github.com/Cotya/magento-composer-installer.
The issue is sometimes my Magento modules don't install correctly and I need to clear the cache, reindex or some other task to get everything 100%. The issues occur sporadically so I haven't been able to script a fix into the deployment process.
What I would like is on deploy Capistrano does not change the symlink to the new build straight away. Instead I am able to preview the site on another link, fix what needs to be fixed, then change the symlink manually.
Is this possible to set up using Capistrano?
If not, my other solution to this is to use the Magento maintenance flag however I would rather avoid having to put the site in maintenance. Open to other idea's as well!
Thanks
It is probably possible to do this by telling Capistrano to not include the symlink change as part of the process (something like Rake::Task["deploy:symlink:release"].clear_actions), and then running that manually (cap [env] deploy:symlink:release).
However, under the category of "Open to other ideas as well!" I'd suggest that you set up a staging site. Create a process to automatically restore a prod database back to stage, then deploy your code to stage and check it there. Once you have confirmed it works, deploy to prod and let the symlinks automatically do their job.
Is there a way I can get a list of what/where Compass installs things when I set up a project? I would like to move away from using Compass and deal with SASS directly.
Nothing against Compass, it's great, but I've found it to be too much for my needs :(
While I have removed the gem (along with the rbenv shim) and migrated my config over to a YAML file in my project, Travis cannot build the site. Looking at the error, it seems like CI expects there to be a travis.yml file, but I never configured one to begin with, IIRC.
Resolved. Travis CI connectivity was flaky and the service needed to be deleted from the GitHub side.
We're using composer, satis and SVN to manage our in-house PHP libraries.
We commit changes to SVN trunk during development, then tag versions (following semantic versioning) when they're ready for testing.
Once a library version is tagged, we can use composer as part of our deployment to the testing environment. Following successful testing, we'd then deploy that same version to production.
The issue here, is that once we've tagged a version for testing, we have to be very careful as the newly tagged version will be picked up by composer when preparing the next prod release.
What I'm imagining, is that we'd tag a version as a beta or RC, (eg v1.1RC1) and somehow configure our deployment process such that it will refuse to deploy an RC or beta to production. If a version is tested successfully, we'd re-tag that version as a released version (v1.1RC1 -> v1.1) and release that.
Can this be achieved?
From what you are saying, I understand that you are actually afraid of tagging a new version of a library because that code could actually be used and break that other application, right?
One approach would be to do good testing. I don't see it should be a problem to tag a version of a library. If the tests are all green, there should be no reason not to tag it. This would work even if the tests are basically only "let's see if it works, manually".
Now the second step is to integrate that new version into the application: Run composer update and see if the application is still running, i.e. start all the tests and wait for green.
I guess it might be a good idea to have a separate area where you check out the application, intentionally run composer update to fetch all the newest libraries, run all the tests and report that a) there are updates and b) they work. A developer should then confirm the update, i.e. do it again manually and commit the resulting composer.lock file, or grab the resulting lock file from that update test.
I don't think there is benefit in using non-production release versions. You have to deal with the next version anyways - constantly toggling the minimum stability setting or adding #RC or #beta flags to the version requirements of the library don't really help.
I'd like to develop a heroku app with the neo4j addon, and i've followed the instructions here but I'm lost as to how to integrate the heroku-like environment variables into my local development environment.
My major goals:
Make things behave as similarly as possible to the deployed app.
Allow me to run automated test suites locally.
Allow me to run the app locally, for quick development iteration.
The only heroku helpcenter article I've found (here) that deals with this seems to recommend always deploying, but this means I have to check-in and push every little edit I make, syntax errors and all, and doesn't allow for running automated tests locally.
It seems like there should be a way for me to edit my Foreman Procfiles to get the desired behavior, but I don't see how I can do that without affecting the deployed processes as well.
This article seems to be what I needed, although I'm still not sure how I was supposed to find it: https://devcenter.heroku.com/articles/config-vars#local-setup
In summary, you can do heroku config > .env to install the production environment locally, then edit the file as needed. Foreman then uses this file to set environment variables.
The article recommends adding the .env file to .gitignore, but as far as I can tell, checking it in is safe since it seems heroku seems to already override it.
I know Rake stands for Ruby Make, and I know Make is a unix build utility. Now, I come from working in Xcode building iPhone apps to Ruby, so I have never used Make before, and the only time I use rake is when in rails or installing some third party package and I type a command like rake db:migrate. The things I don't understand are ... What exactly is a build utility? What is the purpose of rake? What does it let me do? So if anyone can help answer any of these questions for me, it would be much appreciated.
Rake lets you script certain tasks on a per-project basis, much as a Makefile allows a Unix developer to script their compile and build process. The defined tasks you've used Rake with so far were included with the packages they came with (e.g. rake db:migrate comes with Rails, or at least with ActiveRecord) and automate certain tasks related to those packages (e.g. installing required gems for a Rails project).
If your project has certain tasks which are performed repeatedly, you can write a rake task to run those tasks which gets included in the SCM tree for the project and runs in the context of that project; in Rails they're in lib/tasks. You could write a Rake task to purge stale session records from your database, for example, and then set up a cron job to run it.