Clarify GITHUB_TOKEN rights

[dbischof90]

Hi! I'm setting this action up for a pipeline based on Gitea, not Github. For this I need to understand which rights you require from GITHUB_TOKEN so that I can replicate this on my side.

If you'd create a PAT, which rights would it need?

[mikepenz]

@dbischof90 This slightly depends on the specific configuration. However, the action only requires read rights as it does not create a release. It solely focuses on creating the release notes, and the usage for that is afterward open for the specific usecase.

• read for Pull requests
  • that should be covered by the pull-requests scope
• read for Commits
  • that should be covered by the contents scope
• read for Tags (if not available the from and to refs have to be provided)
  • that should be covered by the contents scope
• read to list reviews
  • that should be covered by the contents scope

It's worth noting that pull requests may not be required if the commitMode is enabled.

I don't see any other needs. Usually the above are covered by default Github Actions token scope.

[dbischof90]

Hm, that doesn't seem to be it... That's the current output I see in act_runner:

[...]
::group::📘 Reading input values
GITHUB_WORKSPACE = 'C:\Users\xxx\.cache\act\xxx\hostexecutor'
repositoryPath = 'C:\Users\xxx\.cache\act\xxx\hostexecutor'
Configuration file not provided.
ℹ️ No configuration provided. Using Defaults.
Resolved 'owner' as xxx
Resolved 'repo' as xxx
::endgroup::
::group::🔖 Resolve tags
::error::Bad credentials
[...]

I created a token with read rights to pretty much everything besides admin stuff:

Seems to be a bit more to that. Any guesses?

EDIT:
Hm, it's possible that octocat is not fully compatible with Gitea here although I'd need to investigate that - I have no experience in debugging GH Actions. If I have time I'll create a fork.

[mikepenz]

Unfortunately, I don't have experience with gitea, but as you already note in your edit this action uses the octacat package for doing API requests to the GitHub API.

You can launch this repository using GitHub codespaces and within there you can set-up a test case (with your configuration) and execute that test within a javascript debug terminal. This will offer you full capability to step and debug through things with breakpoints.

https://github.com/mikepenz/release-changelog-builder-action?tab=readme-ov-file#local-testing-

[dreamncn]

@dbischof90

I apologize for replying under a closed issue.

This repository uses the compareCommits API of octokit. You can find the implementation here: link.

In octokit, it makes an HTTP request to /repos/{owner}/{repo}/compare/{base}...{head}. You can see the code for this request here: link.

However, Gitea does not have an API named /repos/{owner}/{repo}/compare/. It may be necessary to develop a new library to replace octokit.

[mikepenz]

Thank you for adding additional context. If somebody knows how to work around that limitation I could look into that, but as mentioned before I don't have experience with gitea so I wouldn't be able to test it.

[dreamncn]

Thank you for adding additional context. If somebody knows how to work around that limitation I could look into that, but as mentioned before I don't have experience with gitea so I wouldn't be able to test it.

I forked your repository and am extracting all the parts that involve octokit calls. This way, I can extend the Action to support more types of action CI/CD systems. Wait for my good news!

[dbischof90]

I did not expect that - great news! :)

[mikepenz]

@dreamncn thank you so much. Really appreciate you looking into this!

[dreamncn]

It seems to run fine on Gitea, I'll refine the test cases tomorrow before submitting a PR.

[mikepenz]

Wow that was fast. Impressive!

[dreamncn]

@mikepenz @dbischof90 I have successfully completed it. For details, see PR #1273

[mikepenz]

The PR was merged and is released as part of v4.1.0 @dbischof90

Thanks for the awesome contribution @dreamncn