[BUG] Unable to find previous tag during a release action trigger

[rodrigocollavo]

Is there an existing issue for this?

• I have searched the existing issues

Does this issue exist in the latest version?

• I'm using the latest release

Describe the bug?

Description
I'm using a workflow with a 'released' trigger, depending on the repo, there are cases where the previous tag can't be found and the action fails.

Details
The code is using the command git log --sort=-version:refname to extract all tags, and it considers the second of the list as the previous tag, required to compare files later.
The problem occur when there are some other existing tags in the repo not following the semantic version.

To Reproduce

For instance, let's say I'm following the semantic version 0.1.0, 0.1.1, 0.2.0, but I also have some old tags v0.0.0, testing-xx, and I release a new version using the tag 1.0.0. Then, when I run git tag --sort=-version:refname, the order is the following:

v0.0.0
testing-xx
1.0.0
0.2.0
0.1.1
0.1.0

What OS are you seeing the problem on?

ubuntu-latest or ubuntu-20.04

Expected behavior?

Option 1: Enforce semantic version, that can be a blocker for new adopters.

Option 2: Add a filtering logic, to consider valid tags those using semantic version only, or specify a pattern to filter (either to whitelist or blacklist)

Relevant log output

Run tj-actions/changed-files@v37
changed-files
  Using local .git directory
  Running on a release event...
  Error: Similar commit hashes detected: previous sha: c7a3f1b3b2c1ed9344fd21130ca9ceede9035828 is equivalent to the current sha: c7a3f1b3b2c1ed9344fd21130ca9ceede9035828.
  Error: Please verify that both commits are valid, and increase the fetch_depth to a number higher than 50.
  Error: Similar commit hashes detected.

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

Thanks for reporting this issue, don't forget to star this project if you haven't already to help us reach a wider audience.

[jackton1]

Hi @rodrigocollavo this should be resolved in the latest v38 release.