I finalized my last work on a git branch and merged it to the branch for my staging environment. But after my Capistrano Deployment Script finished i rubbed my eyes, because although my changes are pushed to Github my last Commit was completely ignored. They point is that even the remote branch points to the real last commit, but that is not recognised by capistrano for some reasons. Any Ideas?
Capistrano 3 maintains a mirror of your Git repo on the server. It is stored alongside the current, releases, and shared directories in a directory called repo. Usually that means it is here:
/var/www/my_app_name/repo
If you are absolutely sure that the remote is up to date and yet Capistrano is not seeing it, then perhaps there is something wrong with this cached repo.
Try deleting the repo directory (or move it to a backup location) and deploying again. Capistrano will recreate it and hopefully pick up your new commits.
I found the Problem. There was a bad entry in the hosts file which leads to that strange behavior. Thank you for your efforts.
Related
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.
Ok, Using capistrano 3.2 with Rails 4.2.
Put simply I want to have each release on the live server to have an intact git repo with it. I know Cap uses git to clone the files but afik it deletes the .git folder by default. I swear I had this working before on earlier versions of Capistrano but no amount of Docs or Googling is finding the right setting. Or if I had an odd version of Cap
And before I get jumped on with "Version control on live? Never make changes to live, develop on your dev server you idiot!?"
Having an active git repo on live is invaluable if something changes out of your control, or if there is an emergency you have no choice but to monkey patch. Because now you have the change shown up by git and you can commit it, and push it back into your central repo and have it go up stream neatly. Its saved my ass before and means I don't have to copy by hand what I know has fixed the "live" issue.
Anyway, justification over. Anyone know how?
I apologies for the simple question, I think it's unlucky google fu which has left me without an answer from searching for this. Searching "Capistrano leave git on live" or other such terms are swamped with using git to deploy.
Cheer in advance.
This would be non-trivial. Capistrano uses git archive piped through tar to create the release folder. Hypothetically, you could override the task which does this, but you would probably spend more effort than it would be worth. I would highly recommend that you look at just creating a workflow where you commit a hotfix and push again. We use a prod branch at which the production deploy points, thus you could commit the change to the prod branch and cap production deploy, then merge your change back down to your development branch.
If you do choose to try and override this, look at the Capistrano source for the git tasks. It uses the Git Strategy class, so you would need to subclass and override it, then override the task to use your class. Capistrano is basically just a subclass of Rake, so look for documentation around overriding a Rake task, e.g. Overriding rails' default rake tasks.
Good luck!
I hope this is an ok question for StackOverflow. If it isn't, let me know. Thanks!!
I have my first Rails app about to go production. I'm using GIT and Github for version control. And I'm using CAP to deploy to our own servers.
We have one server for Staging and one for Production.
So, lets say it's day one of production. And I'm also coding new features on my iMac. So, I'm making changes and saving to GIT, Github and staging.
But, then the users run into a small error that I need to make a quick fix on production.
Well, I've already started making major changes to the code and I don't want to put that into production.
How would I make the quick fix the users need?
Thanks for the help!
Ill assume you have a prod branch and a devel branch, and the tip of prod is what has been released to prod.
You can;
1. git stash all your current work if you havent committed it yet.
2. git checkout prod
3. Create a new branch for your hot fix, fix it, merge it back to prod and release it.
4. git checkout devel and git stash apply your stash if you need to.
5. git merge prod into your devel branch so it has the hot fix you just deployed.
If you dont have separate branches for prod and devel, now might be a good time to set them up :)
See the section 6.3 Stashing of the progit book.
http://git-scm.com/book
You may create a branch for fixies, fix a bug there, and update your application on production server with this branch. In some moment you will merge them (branches).
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 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>