Prevent setting coverage note on pull requests

[lazyguru]

Fixes #74

Another side-effect of running from a public fork that I found was that you cannot add comments to the PR. However, this is solvable by setting add-comment: false (alternatively, I suppose using a PAT would allow adding comments, but for our use-case we don't want to do that)

[tturbs]

I wasn't able to check this PR before pushing another one. Since they might be the same issue, accepting either one should be fine. However, if events other than push and pull_request (such as tag) trigger the build, my PR might be more effective.

[lazyguru]

These are not the same thing. My issue (which this PR fixes) is that a fork does not have permissions to add push notes to the repo it was forked from in a pull request.

[tturbs]

I haven't tried to reproduce this problem yet. I'm not sure if I understood correctly, but I understood that the repository fork-er don't have git push permission for notes. There is a mention about setting read and write permissions in the README, but is this a different situation?

[lazyguru]

It is not possible to grant permissions to a fork of a public repo to be able to update the original repo (without obviously have the PR merged by someone with write access). GitHub does not support this (I can try to find the docs on this again later)

[tturbs]

I understand.
However, the situation in which I’m using this app is that I’m making a pull request (PR) within a repository branch, and the trigger condition is pull_request. So, if this PR is accepted, it won’t git notes in my case. Could you add the option to ignore only the pull request triggers in cases where authentication cannot be granted?

[lazyguru]

The git notes are still updated, it's just that they are only updated AFTER the PR is merged (instead of the current way where it updates the notes while the PR is open).

[lazyguru]

I can try to find the docs on this again later

I believe this is the doc I was referring to: https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#permissions-for-the-github_token note the last column for "Maximum access for pull requests from public forked repositories" where all are capped at "read". Yes, you could use the pull_request_target event instead, however there are security implications with that and (IMO) it almost feels like GitHub said "here, if you want to play with matches while standing in a puddle of petro we won't stop you - just don't say we didn't warn you"

[tturbs]

To follow your �explanation, I would need to trigger go-coverage on the branch push as well. Additionally, the details should be documented in the README.

[tturbs]

LGTM

[lazyguru]

To follow your �explanation, I would need to trigger go-coverage on the branch push as well. Additionally, the details should be documented in the README.

Good point. I'll double-check things (I'm using this in another repo so I will verify it is working as I've described) and then update the README in this PR to mention that as well