We use git (github) and capistrano (like 99% of the Rails shops out there) to deploy our app to production.
What I'd like to do is, after every cap * deploy generate a text file containing all the git commit comments since the last deploy. I can then take that list of commit comments, clean it up, and put it somewhere for consumption.
"git log" http://book.git-scm.com/3_reviewing_history_-_git_log.html has plenty of options for fetching log messages, but I don't see an easy way in capistrano to return the current and previous commits, or even the last date/time a deployment occurred, so I can pass that to git log
Thoughts? I can't be the first one doing this... Thanks!
If capistrano doesn't do this, you can wrap it in another script/tool, say, release.
When you launch release, it records the commit, compares it with the previously recorded commit, calls a release notes generator script/tool, and then calls capistrano.
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.
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.
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 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 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>