Git commit is lost after checkout

[13k]

I'd want to tag my app with the current git commit being built (not git tagging, but compile a binary setting a field with the commit hash), but this info is lost after git:clone. I thought of saving the commit myself but before git:clone that's not available, and after that it's already lost.

Using the local repository to get that information is probably the worst solution, since there may be pending commits hanging there, so I'm not even considering this as a workaround.

A workaround is to use commit directly if given, otherwise use git --git-dir=<deploy_to/scm> show-ref -s <branch>, but I think that's not an elegant solution.

I think a good solution would be to have git:clone save git show-ref -s HEAD to a REVISION file after checkout (either via commit or branch) but before rm'ing the local git bare repository (exactly before the "Using this git commit" message).

Besides tagging, another good use case I'd like for myself is to document which commit was used in which version. This way I can debug properly. Another use case would be to use in notifications or logging deployments with timestamp, revision, etc.

[13k]

Since that file would need to be unique for each release, it should probably live in the release directory, but using a safer name like REVISION.mina or something like that.

I think that messing with the release directory is a bad idea, but I don't see any other way of getting that done, unless mina is able to expose global shell variables that can be used within queued commands, is there anything like that in mina? That seems to be a good feature to have generally.

[13k]

Sorry for my verbiage, but thinking more about the shell variable, that wouldn't work if I wanted to access the revision hash after a deploy, using current_path for example. Writing a file would be the only way to achieve this.

Another solution to avoid writing to the release directory would be to have another deploy top-level directory that contains versions-to-revisions information, for example, write the revision to a file #{deploy_to}/revisions/<version>. That way it would be possible to grab the revision via last_version, or even navigate through versions/revisions.

[d4be4st]

does PR #306 solve your problem?

[13k]

👍