forward / capistrano-deploy-tagger

Capistrano-Deploy-Tagger creates and updates certain tags in Git each time you perform a deploy. The first tag defaults to 'inproduction' and is always updated to refer to the revision that was just deployed. The second tag is a timestamp applied to every revision that is deployed to production.

Capistrano-Deploy-Tagger

About

Capistrano-Deploy-Tagger creates and updates certain lightweight tags in Git each time you perform a deploy.

There are two types of tag, the first defaults to inproduction, and is always updated to refer to the revision that was just deployed. This gives you a tag which always points to the latest release to production, or to a staging or test server (in which case you can configure the tag to be intest or instaging in your test or staging deploy script). This can be used in many ways, for example, in an autoscaling environment, to clone the correct release of software.

The second type of tag is a timestamp, and is applied to every revision that is deployed to a server, giving you an easy way to see exactly which revisions have been deployed to a server in the past. This is helpful if attempting to diagnose issues that may not have become immediately apparent. The prefix is configurable here as well, so you can distinguish between different environments/deploy scripts if necessary (default is "deploy-YYYYMMDD-hh-mm-ss").

Note: Capistrano 3 is completely incompatible with Capistrano 2, and therefore Capistrano-Deploy-Tagger will not function with Capistrano 3. If you are using Capistrano 3, you can use Cap-Deploy-Tagger, however note that the configuration is not compatible between Capistrano-Deploy-Tagger and Cap-Deploy-Tagger.

Installing

• gem install capistrano-deploy-tagger

In your deploy.rb:

• require 'capistrano/deploy/tagger'

Now when you run a standard cap deploy, upon success you will see the following line in your output:

• [Capistrano-Deploy-Tagger] Updating deployment git tags...

Overriding Defaults

By default, the first tag which represents the latest deploy is named inproduction. You can change this globally, or for certain cap tasks by setting the following in your deploy.rb:

• set :latest_deploy_tag, "your_tag_name_here"

Likewise, the prefix for the timestamp tag (by default deploy) can be changed globally, or for certain cap tasks or environments by setting the following in your deploy.rb:

• set :latest_deploy_timestamp_tag_prefix, "your_timestamp_tag_prefix_here"

You can also change the timestamp format (by default %Y%m%d-%H%M-%S), again globally or for specific cap tasks, by setting the following in your deploy.rb:

• set :latest_deploy_timestamp_tag_format, "%Y%m%d-%H%M%S"

where the format is any valid strftime format.

You can also disable updating tags, again globally or for specific cap tasks, by setting the following in your deploy.rb:

• set :update_deploy_tags, false

You can also disable timestamp type tags by setting the following in your deploy.rb:

• set :update_deploy_timestamp_tags, false

Special Usage

You can force Capistrano to deploy from the inproduction tag, and prevent Capistrano-Deploy-Tagger from updating any tags by running your deployment like so:

• cap automatic deploy

The automatic task overrides :branch to set it to the value of :latest_deploy_tag, then sets :update_deploy_tags to false.

This becomes useful if you have an automated deployment system, for example AWS Autoscaling, and need to clone the revision currently in production, rather than just pulling HEAD.

Notes

Originally I wanted to allow the timestamp tags to be deleted, keeping only a configurable amount of the most recent, however there are problems with this. When another user pulls the repository, they pull down the tags. If one of those tags is then deleted, they retain their local copy of it, and things then become confusing for everyone. If you update the revision a tag refers to, this doesn't seem to be an issue however. If this changes in the future I'll take another look.

capistrano-deploy-tagger's Issues

License missing from gemspec

RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.

via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can imagine, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.

There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!

Appendix:

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies

p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post about this project for more information.

trouble with the sha1 hash and tagging

I had some problems with this not tagging any check-ins till I debugged it to find that the sha1, 'latest_revision' was being prefixed with a newline. [I'm using Capistrano 2.15.4 and Git v1.7.9.5].

Adding .strip to the strings where it is used, or, slightly more hacky but in a single place - fixes it:

      email = git("config --get user.email", {:output => true})
      latest_revision.strip!

Note: .chomp will only remove trailing characters - .strip trims whitespace from either end.