Rails 4 application.
Using Cloud9 editor (Not AWS)
Question:
I was getting several errors in my Heroku app when I tried to push my completed work. It was showing a Segmentation fault error. My mentor suggested I delete and recreate the app and try to redeploy. Like the noob that I am, I deleted the application from my Heroku repository instead of destroying it in my Rails console. I proceeded to with a heroku create command and created a new app. However, when I went to git push heroku master it references the old app and gives a fatal: repository 'https.....' not found error.
How do I destroy the old app when the repository is still referenced/embedded in my code. Any suggestions would be greatly appreciated.
from your command line, execute heroku apps:destroy
if it doesn't work, check your Git remote repository list by executing git remote -v
if there is "heroku" in the one of the list, then delete it by git remote rm heroku
and then create new Heroku app as what you do usually
My app runs properly locally and has a crash when it runs on Heroku. The app does fine until I run a new_post_path call. I tried git push to see if a change to the new.html.erb file or the _form.html.erb file was the issue - but I think during the last push to heroku - my database may have taken a hit. At the time I was adding a t.text field (longtext) and it seems to be the issue.
So I wanted to roll back or totally re-start at heroku. But I have not found anyway to do it. Since this is not near production yet. Is there anyway to just create a new instance at heroku and push up to it?
Again, local version runs perfect. Thanks in advance for any ideas.
I would say there are several ways to handle this problem
restarting heroku
Run $ heroku restart in the rails dir. Sometimes I believe in magic.
debugging
Use $ heroku log to debug what is causing the error.
migrate database
Perhaps you made a database change in local rails, while heroku rails didn't.
Run heroku run rake db:migrate
drop database and remigrate database
See this thread. Sometimes old migration might be in conflict with current migration. Do a clean migration, if the data in your database isn't important.
recreate heroku instance
run $ heroku apps:destroy –app appname and replace appname with your appname. Then delete the current heroku remote repository location from git. git remote rm heroku. Then recreate heroku. run $ heroku create. go through pushing your code and migrating database like usual.
Relaunching might be the least of your problems, so I suggest a few things:
Review this Heroku article on releases, including the Heroku rollback feature.
Add the PG Backups add-on to your app.
I also recommend using something like the exception_notification gem in combination with the SendGrid add-on, so that you can get an email with details on the error as well.
please help me,
when I want to upload an rails app to heroku I do this sequence and works creating a new project on heroku
git init
git add .
git commit -m "init"
heroku create
git push heroku master
and then I get a new url like http://-somethingdiferent-.herokuapp.com each time that I need to deploy an project
I dont know how to use that project later without creating other new heroku project
I was thinking to use something like pull of git, but I dont know how is the pull on heroku, maybe -git pull heroku master? but in that case, how can I pull the same project?
please I will like if you know the sequence or any tutorial?
thanks
Try to create an app first
# run this command from the app folder to create a new app
$ heroku open --app the-app-name
# Add it to the remote
$ heroku git:remote -a the-app-name
# push app to heroku
$ git push heroku master
the-app-name shall be replaced by the application name.
one can find more useful stuff here.
I solved my problem while writing this post, but I thought this might be good information for other noobs like me :)
To solve the problem below edit the following file
.git/config
There's a section that looks like this
[remote "heroku"]
url = git#heroku.com:adjective-noun-1234.git
fetch = +refs/heads/*:refs/remotes/heroku/*
This is what git tries to push to. Just change the line
url = git#heroku.com:adjective-noun-1234.git
to whatever new Heroku project you created. Git should now be able to push to Heroku again.
I have gotten my second Rails app ever to a working state and want to deploy it. So I followed all the steps for Heroku deployment in the Ruby on Rails Tutorial (I had the deployment working for the sample app from the book) using:
heroku create
I then push my project with
git push heroku master
The project doesn't work although I can't find any errors in the Heroku logs, all I get is:
We're sorry, but something went wrong.
We've been notified about this issue and we'll take a look at it
shortly.
So I looked around the Heroku Support Section and found the official Rails 3.0 / 3.1 deployment guide:
http://devcenter.heroku.com/articles/rails3
http://devcenter.heroku.com/articles/rails31_heroku_cedar
I went to the Heroku Web Frontend > General Info > Destroy App because I wanted to continue my efforts with a clean slate.
Following the guide I created a Heroku project for the cedar stack:
heroku create --stack cedar
And push it to Heroku using
git push heroku master
THE PROBLEM: for some reason git is still trying to push to the old Heroku project!!!
resulting in an error
fatal: The remote end hung up unexpectedly
Check your remote repositories, and update it to the new heroku name:
git remote -v
Then remove the heroku one that is wrong:
git remote rm heroku
Then add the new one
git remote add heroku git#heroku.com:sitename.git
This is a bit extreme, but worked for me....
heroku destroy appname
heroku create
git push heroku master
I have a slight annoyance with my heroku push/deploy process, which otherwise has been a joy to discover and use.
If i add a new migration to my app, the only way i can get it up onto the heroku server is to do a push to the heroku remote. This uploads it and restarts the app. But it doesn't run the migration, so i have to do heroku rake db:migrate --app myapp, then heroku restart --app myapp. In the meantime, the app is broken because it hasn't run the migrations and the code is referring to fields/tables etc in the migration.
There must be a way to change the deployment process to run the rake db:migrate automatically as part of the deploy process but i can't work it out.
Is it something i set in a heroku cpanel? Is it an option i pass to heroku from the command line? Is it a git hook? Can anyone set me straight? thanks, max
Heroku now has the ability to handle this as part of their "release phase" feature.
You can add a process called release to your Procfile and that will be run during each and every deploy.
Rails >= 5 Example
release: bundle exec rails db:migrate
Rails < 5 example
release: bundle exec rake db:migrate
What about this simple command chaining solution:
git push heroku master && heroku run rake db:migrate
It will automatically run the migrate as soon as the first one finishes successfully. It's tipically 1-2 seconds delay or less.
Here is a rake task that wraps up everything into a one-liner (and also supports rollback):
https://gist.github.com/362873
You still might wind up deploying on top of your boss's demo, but at least you don't waste time typing between the git push and the rake db:migrate.
I created a custom buildpack that gets Heroku to run rake db:migrate for you automatically on deployment. It's just a fork of Heroku's default Ruby buildpack, but with the rake db:migrate task added.
To use it with your app you'd do this:
heroku config:set BUILDPACK_URL=https://github.com/dtao/rake-db-migrate-buildpack
Also note that in order for it to work, you need to enable the user-env-compile Heroku Labs feature. Here's how you do that:
heroku labs:enable user-env-compile
And here's my evidence that this works:
Perhaps you could try separating your schema commits (migrations, etc.) commits from code commits (models, validations, etc.).
(Note the following assumes your migration changes are NOT destructive, as you've indicate covers most of your use cases.)
Your deploy process could then be:
Push schema changes to Heroku
migrate
Push application code to Heroku
This is of course far form optimal, but is an effective way to avoid downtime in the situation you've described: by the time the app receive the code for the dynamic fields, the DB will already have migrated.
(Of course, the simplest solution would be to simply push and migrate while your boss is out to lunch ;-D)
Otherwise, even if schema modifications were carried out automatically you'd still run the risk of a request passing through right before the migrations have been run.
Just for those googling folks like me I want to give a plain solution here.
I am using Rails 4 and needed to add a simple Rake task to the deployment to heroku. As I am using the 'deploy to heroku' button in github there is no chance to run "heroku run ..." immediately after deployment.
What I did: I extended the standard Rake Task 'assets:clean' that is automatically run during a deployment to heroku. The task still runs normally but I have attached my own stuff to it's end. This is done with the 'enhance' method. In the example below I add a db:migrate because this is probably what most people want:
# in lib/tasks/assets_clean_enhance.rake
Rake::Task['assets:clean'].enhance do
Rake::Task['db:migrate'].invoke
end
I admit that this is no perfect solution. But the heroku Ruby Buildpack still does not support any other way. And writing my own buildback seemed a bit of an overkill for so simple a thing.
I use a rake task to put the app in maintenance mode, push, migrate and move it off maintenance mode.
I wrote SmartMigrate buildpack which is a simple Heroku buildpack to warn of pending migrations after a ruby build whenever new migrations detected. This buildpack is intended to be part of a Multipack that has a preceding Ruby buildpack.
With due respect to other solutions here, this buildpack has 3 advantages over those:
No need for maintenance mode
No need for out-dated ruby buildpack forks that just insert the migration at the end
No need to run migrations ALL THE TIME, a warning is only displayed if new migrations are detected since the last deployment
I think David Sulc's approach is the only one which ensures that you avoid requests getting through while the app is in a broken state.
It is a bit of a pain, but may be necessary in some circumstances.
As he stated, it does require that the db migrations are non-destructive.
However, it can be difficult to push your migrations and schema changes prior to the rest of the code, as the obvious approach ('git push heroku {revnum}') relies on you having checked the migrations in before the rest of the code.
If you haven't done that, it's still possible to do this using a temporary branch:
Create a branch, based at the git revision that you most recently pushed to heroku:
git branch <branchname> <revnum-or-tag>
Check out that branch:
git checkout <branchname>
If your db migration commits only contained migrations, and no code changes, cherry-pick the commits that contain the database changes:
git cherry-pick <revnum1> <revnum2>...
If you commited your db changes in revisions which also contained code changes, you can use 'git cherry-pick -n' which won't automatically commit; use 'git reset HEAD ' to remove the files that aren't db changes from the set of things that are going to be commited. Once you've got just the db changes, commit them in your temporary branch.
git cherry-pick -n <revnum1> <revnum2>...
git reset HEAD <everything that's modified except db/>
git status
... check that everything looks ok ...
git commit
Push this temporary branch to heroku (ideally to a staging app to check that you've got it right, since avoiding downtime is the whole point of jumping through these hoops)
git push heroku <branchname>:master
Run the migrations
heroku run rake db:migrate
At this point, you might think that you could just push 'master' to heroku to get the code changes across. However, you can't, as it isn't a fast-forward merge. The way to proceed is to merge the remainder of 'master' into your temporary branch, then merge it back to master, which recombines the commit histories of the two branches:
git checkout <branchname>
git merge master
git diff <branchname> master
... shouldn't show any differences, but just check to be careful ...
git checkout master
git merge <branchname>
Now you can push master to heroku as normal, which will get the rest of your code changes across.
In the second-to-last step, I'm not 100% sure whether merging master to {branchname} is necessary. Doing it that way should ensure that a 'fast-forward' merge is done, which keeps git happy when you push to heroku, but it might be possible to get the same result by just merging {branchname} to master without that step.
Of course, if you aren't using 'master', substitute the appropriate branch name in the relevant places above.
I've been using the heroku_san gem as my deployment tool for a while. It is a nice small, focused tool for the push + migration. It adds some other rake commands that make accessing other functions (like console) easy. Beyond not having to remember database migrations, my favorite feature is its Heroku configuration file – so I can name all my servers (production, staging, playground4, shirley) whatever I want – and keep them straight in my head.