Create REVISION_TIME with git commit timestamp upon deploy#2155
Create REVISION_TIME with git commit timestamp upon deploy#2155mattbrictson merged 9 commits intocapistrano:masterfrom G-Rath:support-revision-time
REVISION_TIME with git commit timestamp upon deploy#2155Conversation
mattbrictson
left a comment
There was a problem hiding this comment.
Thanks for the PR! To answer your questions:
do we want to have a dedicated set of tasks, or fold this into the current "revision" based ones?
I slightly prefer the dedicated tasks.
in the context of custom SCMs, do we want to make this an optional extra or required?
For now, I think it can be optional. I personally don't have much recent hg or svn experience, so I hesitate on making it required for those other SCMs. It looks like the only time the fetch_revision_time method is called is by the deploy:set_current_revision_time before-hook that the git plugin registers, so if that method isn't implemented by the other plugins, it shouldn't be a problem.
if the revision time isn't available, do we want to create an REVISION_TIME file at all? (it'd be simpler, but an empty file)
I think we should skip creating the REVISION_TIME file in this case (see inline comment below).
Finally, I think it would be nice to add a feature (cucumber) test for this. Maybe just a simple assertion that the REVISION_TIME file is created upon successful deploy. I'll be merging #2159 soon, which will make it easier to run the feature tests.
| end | ||
| end | ||
|
|
||
| describe "#fetch_revision_time" do |
|
@mattbrictson thanks for the review! I'm assuming based on the comments (or lack thereof) on the PR that my changes already match the opinions you've expressed in reply to my questions, but let me know if that's not the case! In the meantime I'll checkout #2159 and see if I can get a feature test crafted |
This comment was marked as resolved.
This comment was marked as resolved.
| Then(/^the REVISION file is created in the release$/) do | ||
| stdout, _stderr = run_remote_ssh_command("cat #{@release_paths[0]}/REVISION") | ||
|
|
||
| # TODO: confirm that this value is actually constant for everyone |
There was a problem hiding this comment.
give the specs are passing, it seems like these are consistent though I'm still not sure where they're coming from exactly - either way, I'll leave these TODOs in at least until #2159 is landed
@G-Rath I think you're right. Do you mind opening a GitHub issue for this so we can track it as a bug? |
This comment was marked as resolved.
This comment was marked as resolved.
REVISION_TIMEREVISION_TIME with git commit timestamp upon deploy
|
@G-Rath if for whatever reason, someone wanted to disable this new |
|
@mattbrictson the sure fire way would be to ensure that I've not done it myself but I assume they could also remove or override one of the tasks in the chain, such as |
|
Again, not done it myself but this is what I was thinking of - that should be enough right? combined with the task name of |
|
@G-Rath yes, that makes sense. I'll test that out. |
|
This seems to do the trick: Rake::Task["git:set_current_revision_time"].clear_actions |
|
This feature has been released in Capistrano 3.19.0: https://github.com/capistrano/capistrano/releases/tag/v3.19.0 |
…istrano itself (#553) I've upstreamed this into Capistrano: capistrano/capistrano#2155
Summary
The general story behind this is outlined in #2153 - ultimately, this has Capistrano start to manage a
REVISION_TIMEfile which holds a unix timestamp of when the release was committed, in the same way that it stores that releases SHA inREVISION.Resolves #2153
Short checklist
bundle exec rubocop -ato fix linter issues?Other Information
I think this is actually pretty close to being landable since I figured out the general "how" a while ago in another project, but I expect some tweaking will probably be required and it would be nice to support this for svn and hg if possible but I don't use those tools so will either need someone who does to provide insight or I'll see if I can google/chatgpt a solution.
Some general questions I have are:
NotImplementedErrormethods but it didn't seem like they were actually being called by Capistrano itself)REVISION_TIMEfile at all? (it'd be simpler, but an empty file)