-
-
Notifications
You must be signed in to change notification settings - Fork 437
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🎨🧪 Wire linters into the main CI workflow #1652
base: master
Are you sure you want to change the base?
Conversation
61a4226
to
4fe3333
Compare
I'm missing what problem this solves? Conceptually, tests and linting are separate to me, so deserve separate workflows. |
Yes, I understand that the linters may be conceptually different. Though, they still remain in a separate workflow definition file but show up on the same screen with other jobs. As in this graph: https://github.com/nedbat/coveragepy/actions/runs/5526202109?pr=1652. The checks still show up in the same widget at the bottom of PRs too. But wiring that into the unified check job helps prevent forgetting to change branch protection, which also tends to be set by linters. And being able to do so also opens up some possibilities, like file-dependent job runs that can still make use of branch protection (this is the problem I was solving for CPython recently, for example). I see that 4250899 dropped Of course, it's your call, but I've been rolling out this approach of modular workflow definitions in several places recently, and it seems to work very well. |
4fe3333
to
259c135
Compare
259c135
to
d579f73
Compare
I guess I don't understand the reason for making it reusable, just to use it from one workflow? Why not embed it directly in the workflow? I must be missing something. |
Yes, a single workflow runtime is viewable as a single entity on the UI.
It's possible, but it's usually nice to have separate job definitions in dedicated files. Having them in their own files lets us avoid having an oversized main workflow definition that ties them together. At the same time, this allows to consolidate the triggers in the main workflow and not have to keep them in sync through many files. https://learn.scientific-python.org/development/guides/gha-basic/#reusable-workflows
I think the idea here is that yes, it's nice to have modularized definitions for semantically different jobs. And at the same time, it's hard to maintain huge YAML files. So this concept is a good middle ground in my opinion. FWIW, after I used it in a few repos, I liked it a lot and plan to use in my other projects. |
This patch makes the quality workflow definition into reusable. It doesn't need to track the same triggers and conditions as the main one. Additionally, the `alls-green` check can now take into account the outcome of linting making it possible to only have one job in the branch protection.
d579f73
to
94f2975
Compare
This patch makes the quality workflow definition into reusable. It doesn't need to track the same triggers and conditions as the main one. Additionally, the
alls-green
check can now take into account the outcome of linting making it possible to only have one job in the branch protection.