Difficulty with gitflow and tagging

[Ryan]

godel project-version follows the first parent philosophy when computing version numbers, which makes it a bit hard to do version semantics in a git flow way, for example given this commit history with the two branches master and hotfix/0.1.1 and two tags 0.1.0 and 0.1.1

running godel project-version on the commit marked X yields 0.1.0-3-g1234567, when it's probably more desirable for it to yield 0.1.1-1-g1234567 or maybe even 0.1.1-3-g1234567 (since there are 3 commits not on the tag in the ancestry of X (including itself)

This isn't just a problem for hotfixes but also for release branches. I showed hotfixes as an example because sometimes release branches are done with if master is tagged directly

There are degenerate cases to worry about, such as where there are two tags in the ancestry of X and neither is a descendent of the other, perhaps it could just error in such a case.

[Nick Miyake]

The latest version of distgo and godel have added a knob to deal with this.

It is unlikely that we will change the default behavior here -- the default behavior of project-version matches the logic used by https://github.com/palantir/gradle-git-version.

However, projects now have the ability to customize how their version is computed if they want to use a mechanism other than the built-in one.

Add the following configuration to the godel/config/dist-plugin.yml file:

project-versioner:
  type: script
  config:
    script: |
            #!/usr/bin/env bash
            echo "my-version"

The content of the script key will be run as a script, and the output that it produces (that is, prints to STDOUT) will be used as the version for the project. In this example, it hard-codes "my-version". However, if the version is available as an environment variable (or you have some other way to compute it), you can add that logic as needed. The script inherits the environment variables of the process, but also gets an environment variable named "PROJECT_DIR" whose value is the absolute path to the project directory.

For example, you could use a script like:

git -C "$PROJECT_DIR" describe --tags

To generate the version without using the --first-parent behavior (note that, for production, you'd probably need some extra logic like trimming any leading 'v' characters, dealing with cases where no tags exist, etc.).

Hopefully this escape hatch doesn't need to be used regularly. If it does, then I may add some knobs to the default git projectversioner (for example, ability to disable --first-parent behavior). The current design also makes it possible to use assets as projectversioners in the future if we decide that this is something we want to do.