So, I did the "smart" thing of deleting the local branch where I had just fixed a bunch of stuff and now my only working copy of it is in my current heroku release. I tried using git pull and also tried using the process of creating a tracking branch to have a local copy of what is currently on heroku, but neither seems to have worked. When I bring up RubyMine and look at the source files they are the older versions before I updated them with my fixes. Can anyone suggest what I might be doing wrong? I've used heroku/git for a little while now but mainly to push updates to heroku. This is my first time trying to pull code down from it. I am tempted to try using heroku git:clone but worried that might be a fatal mistake if it stomps on my local stuff and then I have no complete working copy. Thanks for your help.
Related
So i've googled this error messages and went through the various stack overflow posts with regards to this. My issue came yesterday when the Dyn DNS were under a DDoS attack. Anyway the initial problem was that when i tried doing git push heroku master it constantly returned everything up-to-date
I tried everything i found in the various relevant stack overflow posts. From doing git remote rm heroku then adding it back, to checking out a new branch then doing git push heroku <branch name>:master but nothing worked.
After trying various other things i gave up and decided to simply delete my heroku app and try pushing all over.
Now the weird thing (which may just be my lack of understanding of how all these works) would be even after deleting my app and not creating a new one, when i run the command git push heroku master it still returns everything up-to-date. Why is that so when there is no longer any app there?
Additionally i have also tried heroku create before trying to push it and it returns everything up-to-date as well. I read that everything is up and running on heroku's side so i'm not quite sure what is the problem.
I can't seem to find any updated documentation on this issue as well so i'm hoping that someone can point me in the right direction or steps to take.
You can try using force (worked for me when I had this problem in the past):
git push -f heroku
This will make Heroku to receive the files and build again, no matter if it thinks everything is up to date. (They even recommend it)
Also, as you've created a new application, make sure you've set the remote to point to this new app:
heroku git:remote -a app_name
I'm having an odd and somewhat confusing problem.
I am trying to install Redmine on Heroku. I followed the instructions and well lets say it hasn't been a smooth ride.
I am now trying to do the db:migrate process. (I had to edit all the cruft in the application.rb to get this far, and don't know yet where this will lead.)
In doing the migration however, I get the message
Plugins in vendor/plugins (/app/vendor/plugins) are no longer allowed. Please, put your Redmine plugins in the `plugins` directory at the root of your Redmine directory (/app/plugins)
Through StackOverflow and some other sites, I have found where this message is generated (environment.rb) and have removed the code that generates it.
However, when I push to Heroku and try the migrate again, the same message reoccurs.
I have tried cloning the Heroku repo/app down to a test directory and when I check the environment.rb file, the code is not there, however if I try the migrate (or any rake task for that matter) the message still occurs. Even from the test directory.
I've looked for the same message in other parts of the code, but haven't found it yet. Have I missed something?
There's one of two things at play here
You're not fixing the problem in your code - running it locally in production mode will show this
OR
You're not pushing your code to Heroku correctly. Are you developing on the master branch? Are you developing in a feature branch? If so, are you pushing that branch into master on Heroku? (git push heroku feature_branch:master)
Okay I figured out what was happening. It's amazing what a good nights sleep can accomplish!
It turns out the cruft in the application.rb file that I mentioned earlier was basically the other files in the config directory appended to app.rb. These included the yml files along with other files like environment.rb and routes.rb. And in amongst this crap was the plugin panic code I had deleted from environment.rb
(It finally came to light when running rake after some changes told me that the application was already initialised!)
So I deleted all this appended nonsense from application.rb and viola! working.
I have no idea why this was done this way as redmine works fine (so far) without it.
I'm working on a rails project that's being hosted on Heroku.
I'm wondering if it's possible to update one file, without restarting the app.
Why. I have a bug, but I can't track it down. It works perfectly on my local system, but it seems to stop mid way through processing on heroku.
As there are no break points, I'm scattering status updates in the code. (to be removed later)
But adding one line of code to a rails app is like a five minute process.
change file
stage file to git
commit file
push git (all the above is quite fast)
wait for heroku to pull down the app, do what looks like a gem install, or at least a gem update.
change a few files to reflect the local url
start up the service again.
Is there a way to push the git without running all those other things? Perhaps a special parameter to add to the push?
A further annoyance is that my git now has a bunch of check-ins that I don't want my co-workers to see. I'm targeting a my own non-production instance of heroku (testing only) and there's no reason to include all these attempts in the global source control.
There's a good reason as to why it's not possible. When you push to Heroku, they produce a 'slug' of your application (https://devcenter.heroku.com/articles/slug-compiler). To provide the massive scalability that Heroku provides this slug is read only so that it can be spun up on multiple dynos which are likely to be distributed across many different physical machines. Each of these dynos runs a separate instance of your application whilst the routing mesh ensures that requests to your application goes to the correct dynos.
Now consider what would occur if any of these instances were writeable, if you're running 5 dynos you'd have your application running on 5 seperate instances - if a file is written how is it then distributed across of your running dynos? Yes, Heroku could have considered some kind of shared file system for running applications out of but that's complicated. By making the file system read only (https://devcenter.heroku.com/articles/read-only-filesystem) this problem is alleviated.
If you've built an app and deployed to Heroku but forgotten to use S3 type peristant storage your application will let you upload files to it (via Paperclip of such like in the Ruby world) but that uploaded asset will only exist on the dyno that received it and will then be lost when new code is deployed or the application restarted as the dyno receives the latest code from the slug.
If you're debugging against Heroku don't forget you've got the usual git arsenal available, git commit --amend. Alternatively work in a branch and deploy that to directly to Heroku (git push heroku <yourbranchname>:master) then when you've isolated the problem rebase (http://git-scm.com/book/en/Git-Branching-Rebasing) your branch onto master squashing any commits you no longer need.
XY Problem
This is a classic XY Problem. X is your non-working code; Y is your search for a non-existent Git misfeature.
How Git Works
Git commits fundamentally work at the tree level, not the file level. As a gross over-simplification, a commit points to a tree, which points to a set of files. When you push a commit, you have to push all the objects related to that commit unless the objects already exist on the receiver.
How Heroku Works
Heroku compiles the application in your Git repository into a slug. While you can ignore certain files during compilation, you can't avoid compiling the slug. That's just the way the platform works.
This is not a problem if you have a reasonable slug size; my Heroku apps only take a couple of seconds to compile. If your slugs are very large, and therefore take a long time to compile (you claim it takes you 5+ minutes), then you have another XY problem on your hands if you're trying to solve for "don't compile."
Debugging on Heroku
Heroku has lots of features and add-ons to aid debugging. Here's a short list to get you started.
interactive console sessions
logging
Exceptional Add-On
See Also
https://devcenter.heroku.com/articles/read-only-filesystem
https://devcenter.heroku.com/articles/dynos#ephemeral_filesystem
It's not possible. The way heroku is setup, every time you push up a change the server will restart.
Yes you can.
First, list all the files that have been modified since the last commit.
git status
Add the files you want to commit individually.
git add location/file_name.rb
git add location/file_name2.rb
...
Make commit to the files you added to push.
git commit -m "committing files one at a time or two at a time"
Now push
git push heroku
This could be a noob problem but I couldn't find a solution so far.
I'm developing a Rails app locally that uses SQLite, I've set up a local Git repo, and the dotcloud push command is using this. Locally I use the dev environment and on DotCloud it automatically uses the prod env, which is great. The problem is that each time I do a push my prod db on DotCloud gets lost, no matter how minor the changes are to the codebase, and I have to run 'rake db:migrate' to set it up again. I don't have a prod db locally, only the dev and test dbs.
Put your DB in ~/data/ as described here and create a symbolic link at deploy time:
ln -s ~/data/production.sqlite3 ~/current/db/production.sqlite3
You should not have your SQLite database file in version control. If you had multiple developers it would conflict every single time somebody merges the latest changes. And as you've noticed, it will also be pushed up to production.
You should add the db file to .gitignore. If it's already in version control, you'll probably have to git rm the file first.
The problem is that every time you deploy, the old version of your deployed app is wiped, and replaced with the new code, and your sqlite db is usually within your app files. I'm not a dotcloud user I don't know it it works, but you can try to setup a shared folder, where you put the production database on the server, which is outside of your rails app.
Not really sure how git is setup on DotCloud.com, but I'm assuming there is a bare repo that you push to and another repo that pull from the bare when a suitable git hook has been executed. You need to find out if you can configure that last pull to use the ours merge strategy.
I like the idea of using submodules, but I am worried that I am leaving my code in someone else's hands. The main issue is that every time I deploy with capistrano, a new copy of the submodule is checked out since I am using:
set :git_enable_submodules, 1
So what happens if someone commits broken code? Then I app breaks on deploy.
Are submodules generally a bad idea unless you control the repository?
If so, is it common practice to just keep a copy of every plugin in your local repo and under your SCM?
Thanks!
Yes, you should keep local copies of everything that may be updated without warning (such as git submodules or svn externals). Take no risk when it comes to deployment on production!
Some even argue you should freeze Rails and all your pure-Ruby gems to the vendor directory as well, so that they only get updated when you want to. You avoid having to install all dependencies on every server you deploy to. This is slightly less relevant now that Rails makes it really easy to install all required gems with a simple rake task, though (rake gems:install).