[WorldMaker]

Yeah, I often prefer, when possible, to automate in CI dumping the git describe output to a .gitignored source file and letting tags themselves be the "source of truth".

Related to that "tags as source of truth" is using tags as a deployment trigger. A release manager applying a tag can be a signal or gate for a version to go to later environments. (For instance: CI builds from main branches stop at Dev environments, CI builds triggered from new tags automatically move on to UAT and Staging environments.)

Also, another tip I've found useful for people with more "monorepos": tag name restrictions match branch name restrictions and you can use a "folder structure" of tags. You can name tags things like subcomponent/v1.0.2. Some git UIs even present such tags as a folder structure. Doing that can confuse git describe, of course, so finding an arrangement that works for your project may be a balancing act. I've used lightweight tags for subcomponents so that git describe doesn't "see them" by default and then you can use the git describe --tags that also takes lightweight tags into account if you need a "subcomponent version" for subcomponent tag triggered deployments (and then you just need to remove to remove the folder prefix).

[aarchi]

> you can use a "folder structure" of tags. You can name tags things like subcomponent/v1.0.2. […] Doing that can confuse git describe

Using the --match option, `git describe --match='subcomponent/*'` fixes this problem. It filters the tags that are considered to only those matching the pattern, so that a later tag for another subcomponent will not be used.