timbertson / autorelease-tagger-action Goto Github PK

compute-tag uses the github API to search for tags, rather than requiring all tags to be present locally:

https://github.com/zendesk/compute-tag/blob/c60e46ca4548d6afdad82160e296b675758ea8c8/action.js#L143-L175

We should either:

• Adopt it wholesale instead of git describe, since it should be faster and removes the need for a deep clone
• Alternatively there could be a switch to control it, if there are features lacking compared to git describe

With the following sequence:

• user creates pr against master, branching off v1.0.0
• new commits are made on master, causing release of v1.1.0
• git describe for your PR build is based off the HEAD commit, which doesn't contain v1.1.0. It reports your current version as v1.0.0 and bumps to v1.1.0, and the git tag immediately fails.

Possible fixes / workarounds:

• merge master into your PR and then re-run, but that's awkward and frustrating on a fast-moving codebase.
• for a PR, don't actually perform a tag. On merge the logic will typically work fine.
• attempt to merge in the main branch right before we detect the current version (but only for a PR)
• for a PR, run describe on the destination branch instead of HEAD

Similar issues on push:

There's a risk of this being a problem on master too, if you have multiple jobs trying to bump the version concurrently. But:

• if the newer commit ends up getting tagged first, you've got a failed job but that commit is included in the latest release (so it likely doesn't matter)
• if the older commit ends up getting tagged first, re-running the job will succeed because the previously-unknown tag will be visible to git describe.