mydrive / capistrano-deploytags Goto Github PK

I had to manually run cap production git:tagdeploy

Hi, thanks for the great plugin!

I've found a rather significant annoyance with the implementation and use of the "-latest" tag. I think the tag should be removed altogether. Tags should almost never be reused, the only sane exception to this is if the tag is local to you and has never been shared. See: http://www.kernel.org/pub/software/scm/git/docs/v1.7.3/git-tag.html (On Re-tagging)

When your plugin does this it causes lots of headaches when working on a project with a team of any size greater than 1. Here is the headache scenario:

1. Alex: cap production deploy - Alex deploys revision abc123 to production

• tag production-2012.05.30-000000 created (referencing abc123) and pushed to origin
• tag production-latest created (referencing abc123) and pushed to origin

2. Alex: cap staging deploy -- Alex deploys revision abc123 to staging
   • tag staging-2012.05.30-000000 created (referencing abc123) and pushed to origin
   • tag staging-latest created (referencing abc123) and pushed to origin
3. Bob: git pull -- Bob now has the following tags -- tag (revision)
   • production-2012.05.30-000000 (abc123)
   • production-latest (abc123)
   • staging-2012.05.30-000000 (abc123)
   • staging-latest (abc123)
4. Alex: Modifies code, commits, and deploys to staging -- cap staging deploy
   • tag staging-2012.05.30-010000 created (ref. def456) and pushed to origin
   • tag staging-latest deleted, recreated (ref. def456) and force pushed to origin
5. Bob: Modifies code, commits, and deploys hotfix to production -- cap production deploy

   • tag production-2012.05.31-000000 created (ref. ghi789) and pushed to origin

   • tag production-latest deleted, recreated (ref. ghi789) and pushed to origin

   • Capistrano deploy errors out with the following:

     To [email protected]:example/central.git
      * [new tag]         production-2012.05.31-000000 -> staging-2012.05.31-000000
      * [new tag]         production-latest -> production-latest
      ! [rejected]        staging-latest -> staging-latest (non-fast-forward)
     error: failed to push some refs to '[email protected]:example/central.git'
     To prevent you from losing history, non-fast-forward updates were rejected
     Merge the remote changes (e.g. 'git pull') before pushing again.  See the
     'Note about fast-forwards' section of 'git push --help' for details.```
     

The problem is that Git will never overwrite a local tag with a changed origin tag. Thus other developers will never see the changed -latest tags unless they deploy to the environment, or manually delete the tag before deploying.

Neither one of those seem to be reasonable workarounds. I'm actually not sure I see the utility of a -latest tag at all. You can always find the "latest" tag with something as simple as: $ git tag -l staging-* | tail -n 1. You could certainly add this as a Capistrano task if you still wanted to provide some access to the "latest" tag. Juggling a tag name among several commits however is a bad practice and should not be used in a library.

Thanks for your consideration and work on this valuable plugin.

-Dave

It would be great if redeploying commits wouldn't produce more tags.

Thank you for your useful script!

The gem does:

        cdt.safe_run "git", "pull", "origin", branch if cdt.has_remote?

but not all git repositories have origin as their remote. This breaks the gem for me. A smarter approach might be to see if there is an upstream tracking branch set for the branch to be deployed, and if so, get the remote from that. Otherwise, refuse to run. And of course it should be possible to override this behaviour by manually specifying the name of the remote:

set :git_remote, 'upstream'

Additionally, I think git pull is an ever so slightly evil thing to do, since it violates the Principle of Least Surprise and could unexpectedly change the working branch. However I understand the need to do it, and I think it's OK as long as this is clearly documented. In particular, if you don't have a separate branch per deployment stage, e.g. if you are using master for everything (agreed - not ideal, but reasonable for a small project with an approach based on Continuous Deployment) then it should be made obvious that this is what's going on.

I added this gem and deployed, and it basically worked, but used the "master" prefix when instead of the appropriate branch name.

triggering after callbacks for `deploy'
* 2013-08-20 15:17:22 executing `git:tagdeploy'
** Tagging 2db8b31a9 for deployment
Counting objects: 1, done.
Writing objects: 100% (1/1), 184 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To [email protected]:ORG/PROJECT.git
* [new tag]         master-2013.08.20-151722 -> master-2013.08.20-151722

I was deploying to my dev environment, from a differently-named feature branch, yet 'master' was used as the tag name. I think it should be possible to make it 'deploy' or have it use the actual branch name (or only run the tagdeploy task on production deploys...)

Some background : In -dev, I dynamically set the branch Capistrano deploys based on my current working branch, with a default of master.

What I guess is happening is your gem needs the branch set at load rather than execution (which seems to explain why the require errors if at top of the file with the branch setting a few lines afterwards)

Following is the code I use in my -dev deploys...

def get_current_git_branch_name
    `git status -s -b`.split("\n").first.match(/##\W(.+)/)[1]
end

task :deploy_working_branch do
    set :branch, get_current_git_branch_name
end
after :dev, :deploy_working_branch

I've been working on similar without realizing you were working on this. I tried to solve a superset of the 'deploytags' problem, including some of the workflow from the older gitflow cap extensions for multi-stage -- I also tried to be much nicer for single-stage cap recipes, without requiring the setting of 'branch' (but also work with single stage where you DO set the branch).

Would you be interested in comparing and contrasting our solutions and seeing if it makes sense to merge them?

https://github.com/jrochkind/cap_git_tools

    def validate_git_vars
      unless exists?(:branch) && exists?(:stage)
        logger.log Capistrano::Logger::IMPORTANT, "Capistrano Deploytags requires that :branch and :stage be defined."
        raise 'define :branch or :stage'
      end
    end

there is check for both :branch AND :stage but in raise there is define :branch OR :stage i belive it should be

raise  'define :branch and :stage'

The timestamps would be better if they were logged in UTC rather than local time because some distributed teams have multiple timezones. Suggestion was made by @tute.

I wanted to try this, so added it to my setup, and got this error :

"*** Capistrano Deploytags requires that :branch and :stage be defined."

There is no mention of additional configuration in the README.

I think it should be documented to at least mention "What?" needs to be defined,
"Where?" it is done, and ideally including an example showing "How?" to do it.

When re-deploying the same version that was previously installed:

To [email protected]:mydrive/project.git
 * [new tag]         project-2012.04.24-165318 -> project-2012.04.24-165318
 ! [rejected]        project-latest -> project-latest (non-fast-forward)
error: failed to push some refs to '[email protected]:mydrive/repo.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

Hello!

Not quite sure if this is the desired behavior, but tags aren't removed on deploy:rollback. Maybe we should have a task for this and make the user manually add the task dependency if he wants it to be fired on rollbacks.

Opinions?

Title says it all; tags are pushed even when --dry-run is specified on the command line.

Consider pushing the just created deploy tag only or force the push.
Log:

failed to push some refs ...
Updates were rejected because the tag already exists in the remote

...because capistrano-deploytags considers it a dirty tree:

*** Preparing to deploy HEAD from branch 'master' to 'production'
*** Whoa there, partner. Dirty trees can't deploy. Git yerself clean first.

I am getting this error when trying to to a simple tagged deploy with version 0.9

LoadError: no such file to load -- /home/brian/.rvm/gems/jruby-1.7.6@ballista/gems/capistrano-deploytags-0.9.0/lib/capistrano/deploy_tags.rb.orig

It seems the recent changes in 0.9 are causing a capistrano-deploytags to attempt to require a .orig file that is not present (Im guessing we don't want to require a .orig file in the first place).

If you need more info let me know, I would be happy to help.

Currently 1.0.4 contains an issue if you try and set the deploytag_commit_message variable since it is not using the fetch(:deploytag_commit_message) method in the helper. Please can you push a version to RubyGems with this applied?

thanks!

Currently having to specify the git repo in order to install master as version 1 is not tagged or published.