if it's a pain to run PyPy tests under coverage, I think it would be fine to do the pypy tests as a separate CI job that aren't run under coverage. None of our code is currently PyPy-specific (we had a workaround for a PyPy bug for a while but it was a tiny branch of code).

Could you fix the pre-commit failures?

According to https://docs.github.com/actions/how-tos/security-for-github-actions/security-guides/automatic-token-authentication, a PR from a fork can never have write access (expect the repo itself).

A relevant bit:

Finally, if the workflow was triggered by a pull request from a forked repository, and the Send write tokens to workflows from pull requests setting is not selected, the permissions are adjusted to change any write permissions to read only.

Maintainers note from the action on the error: https://github.com/marocchino/sticky-pull-request-comment/tree/v2/#error-resource-not-accessible-by-integration

check your Settings > Actions > General > Workflow permissions, and make sure to enable read and write permissions.

The alternative is to provide a GITHUB_TOKEN (defaults to ${{ github.token }}) currently.

@JelleZijlstra I think we need your decision / help here to finish this PR.
If we want to have a coverage report message the action needs write permission on the PR, see links above for the options.
We could also use codecov. I thought it also required a secret token, on a second look it might also without (on public repos). It comes with its own pros and cons.

Read and write permissions for workflows are already enabled, so this might work once we merge it into main?

I'll do a rewrite of the PR. In short a fork can never have a PR comment on pull_request as the permissions / secret is not accessible. I'll shift it to something that should work.

All commit authors signed the Contributor License Agreement.

All commit authors signed the Contributor License Agreement.

-i think i already cleaned commits need to recheck

I've changed the code to a working variant. However, it should be reviewed carefully as we would need to add an exception:

zizmor's warning is correct that workflow_run can be unsafe: See https://docs.zizmor.sh/audits/#dangerous-triggers

Here is a good article about it that I followed to create the new variant: https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/ to avoid insecure pitfalls.

The most important bit, coverage_report.yml does not use execute user code, i.e. code checkout and code run.
The new workflow (and any modifications of it) will only be active after a merge. Any future PR modifying it should be reviewed carefully.

The new workflow consists of github actions and one variable write:

• download a file containing the PR number and store it in the env (more below)
• download the coverage report formatted as markdown
• post the markdown in the respective PR number

zizmor does not report a potentially dangerous GITHUB_ENV write https://docs.zizmor.sh/audits/#github-env

However a user could store what they want in pr_number.txt. Potentially a guard checking that it only contains a small number (so it has to be a PR number) should be added.

As a conclusion to feel save would be to ask someone who is more knowledgeable about the risk to have a look and make a review

Following the guide one could rewrite the workflow to only use github scripts to extract the PR number and write the comment. This would save the call to modify GITHUB_ENV

As a conclusion to feel save would be to ask someone who is more knowledgeable about the risk to have a look and make a review

@woodruffw -- don't suppose you could give this PR a once over from a security perspective, could you? typing_extensions is a top-10 PyPI package, so it's probably better for us to be safe than sorry here!