[BUG] Unable to retrieve previous tag

[tien]

Hi, I got the below error:

I haven't look at the code for this action yet, but it might be due to my versioning following [feature].[patch] instead of [major].[minor].[patch]

[mikepenz]

Is your previous tag v3.0 or which naming do those follow?

[mikepenz]

It may be due to the v or it not following full semver versioning.

You could also try to use the alternative sort approach for retrieving the previous tag:

tag_resolver.method	Defines the method to use. Current options are: semver, sort. Default: semver

[tien]

@mikepenz Yes, the previous version is 3.0. My project is open source so you are free to take a look if that helps https://github.com/tien/pi-hole-connect

[mikepenz]

Thank you I'll try later today. will keep you posted

[tien]

Yeah no worry, thanks for your time man

[mikepenz]

So it's indeed because the version is not semver compliant.

If you enable debug logging you would get the following output:

::debug::⚠️ dropped tag v3.1 because it is not a valid semver tag
::debug::⚠️ dropped tag v3.0 because it is not a valid semver tag
::debug::⚠️ dropped tag v2.3 because it is not a valid semver tag
::debug::⚠️ dropped tag v2.2 because it is not a valid semver tag
::debug::⚠️ dropped tag v2.1 because it is not a valid semver tag
::debug::⚠️ dropped tag v2.0 because it is not a valid semver tag
::debug::⚠️ dropped tag v1.0 because it is not a valid semver tag

You can work around this by using the alternative sort tag resolving logic instead:

Configure with:

{
    "tag_resolver": {
        "method": "sort"
    }
}

in side your configuration.json. See more details in the README please

E.g. like:

{
    "sort": "ASC",
    "template": "${{CHANGELOG}}",
    "pr_template": "- ${{TITLE}}\n   - PR: #${{NUMBER}}",
    "empty_template": "- no changes"
    "tag_resolver": {
        "method": "sort"
    }
}

[ccremer]

Hi. We have the same error in https://github.com/vshn/kube-token-refresher/runs/2964071073. There, the tag v0.1.0 is existing, but it's the first tag, yet it still fails the pipeline.

Is that case expected? We would be fine to just print "first implementation" or so :)

[mikepenz]

@ccremer yes that's currently expected. as a work around you may be able to tag a v0.0.1

Was wondering what a good alternative would be for the first time, was thinking of maybe just using everything in case of no previous tag would be acceptable, but I fear that this may lead to side effects where a different problem lead to no previous tag seen (previous tag too old, ....)

[ccremer]

Yes, creating another tag did work.

Hm, not sure either. Personally I would be fine with just "initial release" or so, since there's no change from a previous release. But yes, if there are no tags detected but the there are old releases, a failure might be a better option.

Does it make sense to add a flag like noTagDetectionBehaviour (better name welcome) where one could choose to like "fail" (abort with error) or "all" (print all PRs in timerange) or "placeholder" (placeholder text mentioned) or something along this idea?

Alternatively, I would also be fine with documenting a warning in the readme that there has to be a first prerelease tag before doing a first release and one should expect to fail the prerelease. Then, when creating another tag, the changelog would look correct and the normal release process can continue. This would actually allow the user to choose where the changelog is starting to show up. e.g. it could be right before the real release to keep changelog small or even empty, or a prerelease tag could be pushed on the initial commit, taking all PRs into consideration. users might still delete the prerelease tag after the first version has been released. If you choose to go this route, I would suggest to add a warning log line if this exact error pops up, that says like

if this is the first tag, please follow documentation on ...someurl

[mikepenz]

@ccremer I believe the best approach for now would be to add the documentation / comment and highlight it to users. having a v0.0.1 tag (not sure if v0.0.0 would be valid) should be sufficient for 99% of all cases. And as you suggest also add the warning in the log

[mikepenz]

@ccremer ok I think after closer inspection I found a good approach to this. pushing a branch. Would you be able to try this out if it works for your case?

https://github.com/mikepenz/release-changelog-builder-action/tree/feature/276

[ccremer]

Thanks for the fast response! I tried it out in a playground repo.

The change: https://github.com/ccremer/modulesync-slave-repo-1/commit/da4fa6f98d7ec642a88b1f665ca2995b7300bb9c#diff-e426ed45842837026e10e66af23d9c7077e89eacbe6958ce7cb991130ad05ada (ignore the rest of the diff) The action: https://github.com/ccremer/modulesync-slave-repo-1/runs/2971342451?check_suite_focus=true The release: https://github.com/ccremer/modulesync-slave-repo-1/releases/tag/v1.0.0 ("no changes")

Run mikepenz/release-changelog-builder-action@feature/276

📘 Reading input values
  🔖 Resolved current tag (v1.0.0) from the 'github.context.ref'

🔖 Resolve previous tag
  ℹ️ Found 1 (fetching max: 200) tags from the GitHub API for ccremer/modulesync-slave-repo-1
  ℹ️ Only one tag found for the given repository. Usually this is the case for the initial release.
  /usr/bin/git rev-list --max-parents=0 HEAD
  28830972421bdb90af0ef5b865ab057a2d7651e1
  🔖 Resolved initial commit (28830972421bdb90af0ef5b865ab057a2d7651e1) from 'git rev-list --max-parents=0 HEAD'
🚀 Load pull requests
  ℹ️ Comparing ccremer/modulesync-slave-repo-1 - 'initial...v1.0.0'

  Error: 💥 Failed to retrieve - Invalid tag? - Because of: HttpError: Not Found
Warning: ⚠️ No pull requests found

[mikepenz]

Thank you. Will use this repo for doing more tests. really appreciate your time and help

[mikepenz]

So I did a change to that branch. One thing to consider though is, this will only work if the action is run within the git project we are targeting for (e.g. it uses git cli to retrieve the first commit) this may be error prone if the action is used without the checked out source

[ccremer]

Ok, I'm not sure what you have changed. I just ran it again and it didn't make a difference. Should there be a difference or was that an internal change only?

One thing to consider though is, this will only work if the action is run within the git project we are targeting for

Fine by me. Again I think the topic "First release" deserves its own section in the readme:

• Either we use the initial commit like the feature branch with the limitation you mentioned
• or users create a "v0.0.0" tag from where they want a changelog to be considered, and remove it afterwards again if desired.

[mikepenz]

the output should now state the git hash instead initial compared to the previous screenshot. Did you change to the latest hash from that branch with the newest commit?

[ccremer]

It still shows initial...v1.0.0: https://github.com/ccremer/modulesync-slave-repo-1/runs/2990279324?check_suite_focus=true No, I just deleted the release + git tag, then pushed same tag again.

[mikepenz]

@ccremer seems it somehow cached the old state. initial should no longer exist there: https://github.com/mikepenz/release-changelog-builder-action/commit/5f56be2bf11739b4245e545e3facd28608049b2b

If you reference towards SHA-1 5f56be2bf11739b4245e545e3facd28608049b2b it should be forced to use the latest.

[ccremer]

Run mikepenz/release-changelog-builder-action@5f56be2bf11739b4245e545e3facd28608049b2b
  with:
    configuration: .github/changelog-configuration.json
    ignorePreReleases: true
    failOnError: false
    commitMode: false
  env:
    GITHUB_TOKEN: ***

📘 Reading input values
🔖 Resolve previous tag
  ℹ️ Found 1 (fetching max: 200) tags from the GitHub API for ccremer/modulesync-slave-repo-1
  ℹ️ Only one tag found for the given repository. Usually this is the case for the initial release.
  /usr/bin/git rev-list --max-parents=0 HEAD
  28830972421bdb90af0ef5b865ab057a2d7651e1
  🔖 Resolved initial commit (28830972421bdb90af0ef5b865ab057a2d7651e1) from 'git rev-list --max-parents=0 HEAD'
🚀 Load pull requests
  ℹ️ Comparing ccremer/modulesync-slave-repo-1 - 'initial...v1.0.1'

  Error: 💥 Failed to retrieve - Invalid tag? - Because of: HttpError: Not Found
Warning: ⚠️ No pull requests found

https://github.com/ccremer/modulesync-slave-repo-1/runs/2990767866 https://github.com/ccremer/modulesync-slave-repo-1/commit/967a395db092cb6a343ede6a342f45da114f8462

I mean it correctly resolves to the initial commit, maybe this is just a cosmetic logging issue?

[mikepenz]

omg. my bad, I forgot to push the updated dist files :( sorry for that

[ccremer]

No worries!

Looking good:

Run mikepenz/release-changelog-builder-action@9126d11d42583086c664ff1fa035004e92b8e7f0

📘 Reading input values
  🔖 Resolved current tag (v1.0.0) from the 'github.context.ref'

🔖 Resolve previous tag
  ℹ️ Found 1 (fetching max: 200) tags from the GitHub API for ccremer/modulesync-slave-repo-1
  ℹ️ Only one tag found for the given repository. Usually this is the case for the initial release.
  /usr/bin/git rev-list --max-parents=0 HEAD
  28830972421bdb90af0ef5b865ab057a2d7651e1
  🔖 Resolved initial commit (28830972421bdb90af0ef5b865ab057a2d7651e1) from 'git rev-list --max-parents=0 HEAD'
🚀 Load pull requests
  ℹ️ Comparing ccremer/modulesync-slave-repo-1 - '28830972421bdb90af0ef5b865ab057a2d7651e1...v1.0.0'
  ℹ️ Found 18 commits from the GitHub API for ccremer/modulesync-slave-repo-1
  ℹ️ Fetching PRs between dates 2021-06-24T09:17:26.000Z to 2021-07-06T08:03:28.000Z for ccremer/modulesync-slave-repo-1
  ℹ️ Retrieved 3 merged PRs for ccremer/modulesync-slave-repo-1
  ℹ️ Retrieved 18 release commits for ccremer/modulesync-slave-repo-1
📦 Build changelog
  ℹ️ Sorted all pull requests ascending: ASC
  ℹ️ Used 0 transformers to adjust message
  ✒️ Wrote messages for 3 pull requests
  ℹ️ Ordered all pull requests into 6 categories
  ✒️ Wrote 1 categorized pull requests down
  ✒️ Wrote 0 non categorized pull requests down
  ✒️ Wrote 2 ignored pull requests down
  ℹ️ Filled template

[ccremer]

And the changelog displays the PRs this time:

[mboaventura]

Hello @mikepenz , We are getting this error when using this action for the first time, but when we re-run the action it works fine. Do you know why it could be failing on the first execution? Thanks in advance

[mikepenz]

Without additional details, I assume the action is run either via a PR from a fork or some other form of trigger where the token does not have the right permission