Thanks, this does seem like it could be useful.

I think it has to be at the root of the repo. Frankly, I wouldn't mind having this live in another repo (similar to how pyright does it https://github.com/jakebailey/pyright-action), the wide variety of project installations and configurations people have might make this an annoying thing to maintain. Speaking of the pyright-action, it does some cool Github magic to have errors show up in your PR, which is pretty nice

I think it has to be at the root of the repo

Not necessarily, it can be in a subfolder, e.g. action, in which case you'd refer to the action as python/mypy/action@master. That said, most users are probably unaware of this, since the vast majority of actions are just org/repo.

it does some cool Github magic to have errors show up in your PR, which is pretty nice

We can add a problem matcher which would convert mypy errors into Github annotations via regexps.

Thanks!

Added #11359 to track documentation for this.

I am working on #11359, I have some feedback on currect state of mypy's GitHub Action:

1. It is not publushed. It might not be a problem at a first sight, but using tags like @master or @latest is not secure. It might lead to unknown results for our end users. Docs: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions I don't want to promote this practice. Please, let's consider publishing our GitHub Action with releases. Docs: https://docs.github.com/en/actions/creating-actions/publishing-actions-in-github-marketplace
2. Our Action is not tested. I test all my custom Actions on each commit, because we can unexpectedly break something: either mypy's CLI or Action spec definition. Example:

• Definition: https://github.com/wemake-services/wemake-python-styleguide/blob/master/action.yml
• Testing: https://github.com/wemake-services/wemake-python-styleguide/blob/master/.github/workflows/wps.yml

3. I don't understand how install_project_dependencies works. It does not look like it supports poetry / pip-sync / pipenv / custom requirements files / etc. Do we really need this?
4. I don't know how I can describe profits of using our own GitHub action over these lines:

name: mypy

jobs:
  lint:
    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-python@v2
      with:
        python-version: 3.9.9
    - run: pip install mypy
    - run: mypy your_path

In the example above you control everything. Python version, extra deps and how to install them, mypy version, its config, security, caching, even custom reporters like https://github.com/reviewdog/
And it is as easy as it gets. While our action does not have all these features. What's our pitch? Why would someone use it over a custom one?

5. I can imagine that our "pitch" can be: "use master-branch version of mypy with all of the latest features", but it is also not true, because our action uses pip install with ==, so only published versions count.

Do others share my concerns?

Please, let's consider publishing our GitHub Action with releases

+1

Our Action is not tested

I can follow up with a test.

I don't understand how install_project_dependencies works.

It uses pip, which should work with any PEP 517-compliant backend.

I don't know how I can describe profits of using our own GitHub action over these lines:

Realistically, you almost always also want to install your dependencies and run mypy with --install-types, which makes the whole thing more like:

name: mypy

jobs:
  lint:
    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-python@v2
      with:
        python-version: 3.9.9
    - run: pip install -e .
    - run: pip install mypy
    - run: mypy --install-types --non-interactive your_path

It's subjective, of course, but a - uses: python/mypy@0.920 one-liner is a lot easier to add by heart, whereas the above will have to be copy-pasted from docs or other projects, and non-trivial workflow copy-pastes tend to drift away from the recommended best practice.

Lastly, this action is modeled after black's, so there's precedent.