Tags aren't removed on deploy:rollback about capistrano-deploytags HOT 6 CLOSED

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:

• I push a tag (e.g. via deploying)
• You pull the repo and get a new tag
• I delete the tag
• You push your tags

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.

from capistrano-deploytags.

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.

from capistrano-deploytags.

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.

from capistrano-deploytags.

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.

from capistrano-deploytags.

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.

from capistrano-deploytags.

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.

from capistrano-deploytags.