search

mydrive / capistrano-deploytags

Add timestamped Git tags for each environment on deployment
BSD 2-Clause "Simplified" License
123 stars 20 forks source link

Tags aren't removed on deploy:rollback #9

Closed pkoch closed 11 years ago

pkoch commented 11 years ago

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?

relistan commented 11 years ago

Glad to see you are using the gem, and thanks for the input.

The unfortunate problem with tags is that deleting them once they have been pushed can be a very hard thing to do, and impossible without cooperation from other people. Imagine the following scenario:

You might expect that the result would be that git would ignore the old tag that had been deleted. But what will happen is that your push will actually re-create the tag I have deleted.

If you are a single user of the repo, this could work. If you are working as a team, you can't guarantee the tag will be deleted. Is it still valuable?

EDIT: It might be possible to wait to push the tags until the very last thing, which would prevent pushing until a rollback has completed.

pkoch commented 11 years ago

I can totally see your point, and you're correct.

My problem with having the tag in a commit which I have successfully deployed and later rolled back is that it might confuse people reading the git log. You have a tag for a deploy, yet there's no deploy on the server with that commit.

relistan commented 11 years ago

Looking at the Capistrano source, it might be possible to implement this using an on_rollback call inside the setup task to prevent tagging in the event of a rollback (rather than trying to delete the tag after the fact). I'll look into it. Here's the method in the Capistrano source that I'm referring to.

pkoch commented 11 years ago

Yeah, having that when tagging would also be nice. However, I was referring to when you run "cap deploy:rollback". In that scenario, yes, you need the whole team's collaboration, as you've pointed out.

relistan commented 11 years ago

I'm going to close this issue, then as I think this is a team workflow issue more than a plugin issue. Thanks for contributing.

pkoch commented 11 years ago

Indeed, the removing the tag part does seem like a workflow issue to me. The only idea I can come up with is to tag the revision again as having been rolled back. Closing the issue seems like the right thing to do.

Having the tag deleted on on_rollback still seems like a good investment, even though it wasn't what I'm looking for.