I commited new version my app on heroku. But it was a bad release.
I got an error The page you were looking for doesn't exist.
I tried heroku rollback, but the error does not disappear.
I want to roll back to the previous commit on Heroku, but not touch the commit on the git.
As per heroku documentation:
The heroku rollback command does not roll back the state of any of the following:
Add-on provisioning (provisioned add-ons remain provisioned, and deprovisioned add-ons remain deprovisioned). Any add-on-related config vars do roll back.
Your app’s Heroku-hosted Git repository
Any state stored in add-ons or externally
It is your responsibility to reconcile these resources after rolling back. Consequently, you should use the heroku rollback command only when absolutely necessary.
Running on a rolled-back release should serve as a temporary fix to a bad deployment. If you are running on a rolled-back release, commit a fix to your encountered issue and push it to Heroku. As always, this updates the heroku Git remote and creates a new release.
So I do not think you can leave the git repo untouched.
Heroku always uses the github branch that you've pushed to it.
The easiest way is to fix it would be to push your github branch to it, without the errors (previous commit).
If you have pushed it to your master branch, you can watch the history of the flawed files and just copy all code that worked in your local branch, push it again to your master (or better, create a branch for it) and push this one again to heroku.
Related
I was playing with my local app, trying to add devise and railsadmin which was disastrous and frustrating. I decided that it's best I just nuke everything that changed and go back to my last working git commit. But somehow my local version is different than my heroku production ver.
How do I get or pull down my heroku version to my local - or get that commit? I am trying to figure it out with docs and CLI commands but things just aren't clicking. I don't exactly understand how the versions could be different. (I made CSS changes during my last commit and it seems my local is a version behind?)
Thank you.
How are you determining "the versions are different"?
As far as I know, if "git pull heroku master" says "already up-to-date", then the last commit on your current branch and the Heroku master branch are the same.
It is possible though that you have local changes which have not been committed to your local repo. In that case, git reset --hard HEAD will throw away your local changes and go back to your last commit. This should be the exact same commit as on Heroku.
(NOTE: only do this if you really want to throw away local uncommitted changes!)
I have this strange issue that my git push origin master and cap deploy it not updating to the latest code and images on production server. I still have old images that I updated localy a long time ago and changes still not reflected.
Is there a way to reset a remote git repo and upload a clean latest version of your local to it?
Or other ways to debug, git status shows no untracked files so I really don't get where it goes wrong.
check your .gitignore file, you could have a line there ignoring these files or entire folders.
check your deploy.rb and multistage deploy files in /deploy folder to make sure that you are using correct branch (master)
When you update an image, commit, push to remote and do cap production deploy:pending do you see your commit listed there as pending deployment?
This turned out to be an SSH timeout on cap deploy, wich I dident have noticed. Resulting in not all commits uploaded thus not seeing my latest commited changes.
Had to upgrade ssh timeout on server.
I will be making changes to a production app soon and I would like to know how to rollback all changes to the database and code. I think with pgbackups and if needed heroku db:push and pull that will rollback the database, but what about the code? Is there a way using git that this could be done, or maybe just to copy the whole folder and copy it back in if there are errors and upload everything again?
Thanks.
For managing your code, use git tags.
Find the commit of the code currently in production and tag it.
Add a new tag to the HEAD commit you intend to push to production
If the code needs to be rolled back, you can target the older tag during your push to heroku.
You can run git log to see the history of commits. Find the commit made just prior to your last push to production. Find the hash for that commit (on the same line as the git message in the log) and tag it
git tag -a v0.1 THEHASH
Now tag your HEAD
git tag -a v0.2
Now push to heroku
git push -f heroku v0.2^{}:master
If things go bad, rollback to v.0.1
git push -f heroku v0.1^{}:master
You can do the pure git workflow, however heroku does support releases.
heroku releases will list all your releases. heroku releases:rollback v1 will create a new release containing exactly your slug as of the v1 release.
Neither this nor the git based rollback would make any changes to your data, so if there were data migrations run they'd have to be manually rolled back as well.
I pushed code to my server using capistrano (using git also).
I then made changes on my laptop, but haven't sinced published to the server.
I want to know which git version I pushed to the server so I can rollback to that version.
Is this possible?
I know I should have used tags but kinda late for that, hoping I can figure out the version I pushed to my server, so I can rollback to that version or at least diff from that version to the current built to see what has changed since then.
Capistrano should have put a REVISION file under #{your_app}/current on the server, with the deployed commit's SHA:
So something like:
git diff `ssh your_user#your_server "cat /path/to/your/app/current/REVISION" `
should get you the appropriate diff.
yes, you can check your reflog.
git reflog
But you should be tagging when you release.
Hope this helps
git fetch
git log origin/master -1
fetch synchronizes with your server and log origin/master shows the log of your server's git repo instead of your local repo. The -1 tells it to only show the last commit. This will show the commit hash and message of the last commit on your server's repo.
If your server is listed in your remotes as something other than origin or your server is using a branch other than master, you'll have to change that. But "origin" and "master" are the defaults and are standard convention if you haven't changed it.
<subjective>
Unless you're explicitly versioning your software (like when creating a gem, for example), it's not necessary to add a tag every time you deploy your app. This would quickly become unwieldy. With git, a commit hash can be used just like a tag if it's ever needed.</subjective>
I had been using a Subversion for my source control, combined with git ONLY to deploy (push) to heroku. My pattern was: Update local working copy from latest master at remote subversion repository. Then do git commit and git push heroku (Git was set to ignore .svn stuff). This working copy I only used to push to heroku, I had another subversion folder for doing live development, and committing to the remote subversion repository for tracking.
I have now switched to git fully. I did a complete import from subversion into a new remote git repository. I've successfully been working on my local working copy of the git repo (origin), and pushing changes when it suits me (also collaborating with one other developer, but I basically run the operation).
MY Question:
I would now like to return to my OTHER git working copy that I had previously been using to push to heroku (that has .svn/ stuff in it as well). I'm thinking of just adding my new git repository as an [origin] entry in the .git/config.. pulling the latest changes from my new git remote, and pushing to heroku, but I'm wondering if it will freak out.
It will try and merge and get confused won't it? AND, even if the pull worked, will the heroku remote get confused about a push that originated from some new git repo?
I could clobber (delete) that working copy (used to push to heroku from subversion), and make a new clone of my new git repository, then add heroku to the .git/config. But I'm concerned pushing to heroku will still cause it to get confused, since I used to push from a different working copy.
Any advice would be great!
Thanks in advance!
If I understand you correctly, you want to switch back to the former SVN repository as your working copy, and you want to preserve the old SVN history?
There are a couple of options available.
Push the recent changes from the new Git repository to Heroku, then switch to the old repository and pull from Heroku. This will bring you old repository up to date.
Temporarily change the URL in the old repository's config file to point to the local path of the new repository. Pull the recent changes from there, and then revert back to the Heroku URL when done. This will also bring your old repository up to date.
The first option is the most expedient, and the second is the long way round. Either way, you will have the same net result of an up to date local repository containing all history. The surplus new repository can be disposed of in either case.
Edit:
To address your concerns about whether Heroku will care about the origin of the commit, in brief, no the repository on Heroku is another git repository that accepts commits from authenticated users.
As long as the credentials are correct, the originating repository does not matter. This is the beautiful thing about DVCS - there is not one controlling or corruptible repository - It is entirely possible for you to now clone from Heroku on another machine and continue work from there. As long as your credentials are the same, the history will show any and all commits you push, but does not care where from.
If your desire is to simply use a clean repository to work with, the new one will be the favorite. The old one can be deleted without ill effects.
To prove this - check the SHA-1 hashes for a commit in both new and old repositories, and you will see they are identical. The hash is unique for all commits, and can be used to check the code integrity at all times. There will never be more than one change for any given hash.
As a side note, the repository is portable in that it is entirely self contained, and can be moved around freely on your storage space, or even be used on external storage such as a USB thumb drive.