Release SHA status information missing

[blackxored]

This has been removed from Capistrano 3, and there's currently no way that I can figure out to accomplish the following:

• Get the SHA of the currently deployed branch. There used to be a REVISION file on the root of every release that you could just read. Not anymore.
• Get the SHA of the previous release, for comparison purposes.
• See what's not deployed yet, there used to be a 'deploy:pending' task just for that purpose, not anymore.

Your thoughts on this?

[seenmyfate]

To answer your first point, it had been my intention to append this to revision.log in the deploy_to directory. It looks like the actual implementation uses the branch name - will gladly take a PR that also includes the SHA in there as well

[blackxored]

This would do it, for now, I got this appended:

Branch master (at c416c6e) deployed as release 20131101162749 by blackxored;

[seenmyfate]

Thanks for this - I think overall I would probably rather see this pushed into a DSL method, maybe capture_revision? I also suspect that it doesn't need to be a lambda (and I'm not really a fan of the [] syntax 😄 ). Still I'm tempted to merge this as is, it's great to have the SHA in the logs

[blackxored]

You're totally right, the lambda is my way of avoiding duplication while conserving locality since I'm not yet familiar with that code. I'm thinking of a 'capturing_revisions' around-like method that yields to the execute. What do you think?

[blackxored]

So, 32920c1 IMHO solves all points:

• No longer a lambda.
• No longer [] syntax vs #call.
• Is a DSL method.
• Re-usable generator-like method.

What I don't like is nested blocks problem, but correct me if I'm wrong this is standard practice with the new Capistrano.

Comments welcome.

[seenmyfate]

Awesome, thanks 👍

[kirs]

@seenmyfate should we cherrypick this commit to 3.1.x branch?

[seenmyfate]

@kirs after pushing 3.0.1 out this morning, I've merged 3.1.x down into master ready to go - I don't think there are any more PRs ready to go in, but I've left it just in case

[kirs]

@seenmyfate oh, I didn't noticed that 😯

I was also thinking about adding the default_stage option to 3.1. What do you think?

[yeldarby]

Is there any way to get back the REVISION file within the root of the current release? Working on an upgrade to Capistrano 3 but we were using that to ensure we pulled the proper file revision from our CDN.

[kirs]

You can generate it manually on each deploy.

[kirs]

This is going to work only with git backend, right? Any ideas to make it universal with any backend?

[leehambley]

Yes, if you like, let's open an issue and make this defer to the new SCM stuff that we got in #828 ?

[yeldarby]

@kirs - any tips on how to do that? I'm really struggling with the upgrade to cap 3, there don't seem to be a lot of tutorials out there and the documentation is a bit sparse after the installation and setup instructions. Are there example tasks out there somewhere to look at?

Edit: if anyone else is looking to do this, here's the task I ended up making that gets the release timestamp and puts it in a REVISION file. Wasn't sure how to get the full hash (fetch_revision appears to give the last few characters only) but this is all I need for my purposes.

desc 'Add REVISION file'
task :updated do
        on roles(:web), in: :parallel do
                execute "echo #{release_timestamp} > #{release_path}/REVISION"
        end
end

And I found EXAMPLES.md inside the sshkit documentation which was helpful as well.

[joost]

This currently does not support branches (and only git of course :)).
See pull request #935 for branch support.