[red-knot] mypy_primer: comment on PRs #16599
Conversation
sharkdp
added
ci
sharkdp
force-pushed
the
david/mypy_primer-pr-comment
branch
from
e5d3857 to
d5382aa
Compare
sharkdp
force-pushed
the
david/mypy_primer-pr-comment
branch
from
d5382aa to
5f92264
Compare
There was a problem hiding this comment.
Could we avoid duplicating this entire workflow and instead use the existing workflow?
There was a problem hiding this comment.
What if there are ruff-ecosystem and mypy_primer ecosystem changes (e.g. for changes in the parser / AST)? Should the generic workflow be triggered twice and manage two separate comments? Or should it be be triggered once and then loop internally? Or should it be triggered once and even try to merge those changes into a single PR comment?
Even in the simplest case (triggered twice), this will require quite a bit of parametrization (from which workflow was this triggered? where do we find the artifacts? what is the artifact filename? what is the special tag to find the comment? …) and branching due to custom logic in the "Generate comment content" step.
I can attempt to do this, but I'd like to know the desired outcome first, because my GitHub actions "skills" are quite underdeveloped, so this will probably take me some time 🙃.
There was a problem hiding this comment.
Hmm, that's a good point. I didn't consider that we may have to run both. So maybe it's fine to keep it as is for now
There was a problem hiding this comment.
There are also advantages to keeping it similar to the mypy_primer workflow at typeshed/pyright/mypy, since I'm fairly familiar with the workflows in those repositories, and Shantanu is very familiar with the workflows in those repositories (and I'm sure Shantanu would be happy to help if we have issues!)
There was a problem hiding this comment.
I didn't copy over the typeshed/pyright/mypy workflow because I'm not sure that the sharding will be helpful. At least for now, the bottleneck is building Red Knot, not running it across on projects.
There was a problem hiding this comment.
Yeah, pyright initially didn't use sharding either. They also started off with a very minimal set of projects to run pyright on, but Shantanu and Eric worked together to expand it over time. After the list of projects grew large, pyright started using sharding as well.
|
Merging this to test it. Happy to make adjustments later. |
## Summary Add a new pipeline to comment on PRs if there is a mypy_primer diff result. ## Test Plan Not yet, I'm afraid I will have to merge this first to have the pipeline available on main.
* main: [red-knot] Rework `Type::to_instance()` to return `Option<Type>` (#16428) [red-knot] Add tests asserting that `KnownClass::to_instance()` doesn't unexpectedly fallback to `Type::Unknown` with full typeshed stubs (#16608) [red-knot] Handle gradual intersection types in assignability (#16611) [red-knot] mypy_primer: split installation and execution (#16622) [red-knot] mypy_primer: pipeline improvements (#16620) [red-knot] Infer `lambda` expression (#16547) [red-knot] mypy_primer: strip ANSI codes (#16604) [red-knot] mypy_primer: comment on PRs (#16599)
Summary
Add a new pipeline to comment on PRs if there is a mypy_primer diff result.
Test Plan
Not yet, I'm afraid I will have to merge this first to have the pipeline available on main.