Building the correct version when current commit has a tag

[mstachniuk]

Consider those steps in CI (it's single run):

./gradlew build       #1 Building version '0.0.7' - reason: shipkit-auto-version deducted version based on previous tag: '0.0.1'
git tag v0.0.7.          #2 Create tag based on version returned from shipkit-auto-version
git push --tags
./gradlew publish   #3 Building version '0.0.8'   - reason: shipkit-auto-version deducted version based on previous tag: '0.0.7'

Those steps looks ok because:

• builds first artifacts, run tests, etc.
• create tag before publishing artifacts, because removing tag is easier than removing artifact from repository in case something goes wrong. The published artifacts shouldn't be removable from repository.

Example run: https://github.com/mstachniuk/shipkit-auto-version-github-actons-and-packages/runs/1215130365?check_suite_focus=true

[mstachniuk]

Additionally you are not able to publish Docker image to GitHub Packages if corresponding tag doesn't exist in repo. So tag needs to be created before publish.

[mockitoguy]

I think we have following options:

1) Allow 0 when counting commits (more-less the approach in PR #31) 2) Don't change existing behavior. There is an easy workaround for the use case: "./gradlew pushTag publish" 3) When the HEAD is pointing to a supported version tag, use it without commit counting

Evaluation: 1) I like the simplicity of this approach. I am a little worried about the "local e2e testing" scenarios. For example: I have uncommitted changes and I'm building a version for local testing. The build produces exactly the same version as the one already published but the behavior is not the same (remember - I had uncommitted changes).

2) Keeping the existing behavior makes the "local e2e testing" scenario cleaner. However, it leads to confusing behavior for users that are setting up the CI pipeline (as reported in this ticket)

3) In theory this caters well to both use cases: "local e2e testing" and "CI pipeline setup". However, it adds complexity.

My POV: I think that 1) is the way to go because it's the simplest and most intuitive approach.

[mstachniuk]

I think the allowing 0 (option 1) or option 3 is a need. Think about following scenarios:

• The last version in repository is 1.1.1.
• Someone clone the repo
• Build the project and got 1.1.2 version. Strange.

Or you would rebuild locally the old tagged version. You checkout the tag 0.5.5, run build, but got 0.5.6. Strange.

Remember also that some projects may also use different languages / builds next to Gradle in one project, so you need run different tools.

In case of uncommitted changes we can think about another behaviour (but it will destroy simplicity) like 1.2.3-timestamp or something

[mockitoguy]

Let's go ahead with 1). I reviewed you PR.