Build - Insert commit hash into token/macro/mtprops content.xml

[trey-kirk-sp]

It would be nice to track what the commit hash was when we build an artifact. It would be handy if we could capture the current commit hash (first 6 or 8 chars is all) and store it on the target artifact, somewhere. For a token, there are several reasonable choices, like a token prop or one of the notes fields. For a macro or mtprops, that might be less obvious. At a minimum, maybe an XML comment in content.xml, assuming MT doesn't prune comments?

[havoclad]

Isn't this what tagging is for?

[trey-kirk-sp]

Isn't this what tagging is for?

Eh, sorta. For artifacts we officially release (someday), I could see this being a tag instead of a hash (in fact, I would insist on it). However during development discussions, it would be nice to validate what hash some dev token was built against. Consider a recent discussion in #maptool-dev where I could've told Jay, "Lib:Dnd5e was built on hash 123abcde" and he could determine very easily if my token was ahead or behind the fix.

[mr-ice]

Can you extract a token where you've put a reference string somewhere, so I can figure out where in the xml it would go?

[mr-ice]

Macros definitely don't have as many choices, not having properties etc to expand upon. But, they could possibly be put into a comment inside the macro command itself.

Something like:

# https://github.com/mr-ice/maptool-macros/tree/master 49203ec

# https://github.com/mr-ice/maptool-macros/tree/<branch or tag> <sha>

I like the idea of possibly just appending a property on tokens though. Same format?

[mr-ice]

@trey-kirk-sp can you ./dockerrun bash and from within run git rev-parse --all to establish that the git in linux can read your .git directory on windows through the mount?

[trey-kirk-sp]

$ dockerrun bash
bash-5.0# git rev-parse --all
6c16b5261dc7da8e0bca9b6d536872cf47cdeb2e
2f7039473cdc83847c51d64431dcc3bf2fe229e5
be1934168978c827199de6a7ad7b8c63f0dcf248
e3cb4a415e86a0125dc623d772e9fc56b2dcc5c7
d5141b7ba6fe118b2c8a41a9b62f249220ce1a0d
e3cb4a415e86a0125dc623d772e9fc56b2dcc5c7
14a43d9e43a2aba2a2be2d5ce2d36362de5e1ce2
14a43d9e43a2aba2a2be2d5ce2d36362de5e1ce2
e46d48a001eff2477e5142a99b833849050a444a
...

[mr-ice]

that's good, so I've got access to the git in the container.

So for Macros we're going with \n\n# https://github.com/mr-ice/maptool-macros/tree/$BRANCHORTAG $SHA\n at the end and for tokens we are going to use <gmName>$SHA</gmName>

[mr-ice]

If the file is modified from the local sha, should I flag that?

Like 6c16b526* where 6c16b526 is unmolested?

[trey-kirk-sp]

If the file is modified from the local sha, should I flag that?

Like 6c16b52* where 6c16b52 is unmolested?

Sure, if it doesn't create more work than it's worth.

I'm still mulling over the macro comment

[mr-ice]

git log -1 --format="%h" for the currently checked out commit

git ls-files -m to show files that are modified from that commit

Based on comment in discord, there is no problem with the macro comment being html style

<!-- https://github.com/mr-ice/maptool-macros/tree/$BRANCHORTAG $SHA -->

Did you want it at the top or bottom (less intrusive at the bottom)?

[trey-kirk-sp]

I like top, better

[mr-ice]

What about using this format:

git describe --tags --dirty

20200622-294-g786d44c-dirty

This shows that we're 294 commits from the tag 20200622 and the sha is 786d44c but the checkout is dirty.

for contrast:

20200622-303-g49203ec

is current clean master

[trey-kirk-sp]

For something that goes in the GMLabel, that's a bit verbose.

[mr-ice]

well, it came with the tag for free when we get around to using that.

I suppose I could throw away the bit up to and including the '-g' for you. :)

[trey-kirk-sp]

Well, the tag is nice if the current hash is a tag. So in that case, use the tag instead of a hash.* But otherwise I would only want to know the hash and it it's dirty. If I want more, I should just go to git and do gitting.

* and for now, not suggesting it's smart enough to figure this out. I envision that would be part of a release build, however that comes about.

[mr-ice]

git describe is how one determines if it is tag instead of a commit, as it specifically searches for a tag reachable from the current commit, and if it has been modified from that tag it adds the bit in the middle (the number of commits and the sha).

from man git-describe

The command finds the most recent tag that is reachable from a commit. If the tag points to the
commit, then only the tag is shown. Otherwise, it suffixes the tag name with the number of
additional commits on top of the tagged object and the abbreviated object name of the most
recent commit. The result is a "human-readable" object name which can also be used to identify
the commit to other git commands.

I'll figure out how to strip it down.

[mr-ice]

Note:

dev-164 branch has working 'assemble' with this, but the extract doesn't do anything with it. We need to remove the comment from the macro and blank or remove the gmName from the extracted tokens to avoid introducing these to the repo.

[mr-ice]

Looks like this was overly aggressive and getting into mouseovers.

[mr-ice]

so if I remove the comment from (e.g.) dnd5e_getMovementStat the mouseover looks fine... Looks like the [r: dnd5e_getMovementStat()] somehow brings that string with the rest (perhaps by being expanded within a [r:]).

I think the only safe thing here is to back out the macro command tagging

[mr-ice]

Currently we recognize that token assets named Lib: will be created with a gmName of the current git release information that we have. This currently is the first 8 chars of the sha, and we are hoping to mark it -dirty when the build is made from objects that have been modified.

The attempt to mark the macros with the same git release information failed because the macro's comments were coming out of the macros and being exposed in user land.

Ideally we have two things going on here.

First #50 wants us to automate building the artifacts. This would be done as part of a release process (and in fact is so now, just manual). The release process requires tagging and so those artifacts should be marked with the release tag.

And also development (pre-release) artifacts should be built as well with git information. In this case the current iteration of a sha + '-dirty' is still desired so we can immediately tell from whence the object came, i.e. for debugging purposes we want to see what the code says it should have been.

So in the case of a tag, use the tag. In the case we are beyond or outside of a tag we still desire an identifier based on the sha.

[mr-ice]

tag = git describe --tags --dirty --abbrev=8
if '-g' in tag:
   use the bit after -g
else
   use the tag

The git describe results in:

clean: Log4MT_v1.0 or RC_0.15-1-177-g245421b8 dirty: Log4MT_v1.0-dirty or RC_0.15-1-177-g245421b8-dirty

and the resulting string attached to the token would then be

clean: Log4MT_v1.0 or 245421b8 dirty: Log4MT_v1.0-dirty or 245421b8-dirty

[mr-ice]

NOTE to developers and releasers:

Strong encouragement to avoid putting '-g' anywhere in a release tag