developer-portal
developer-portal copied to clipboard
Make autoformatting and linting checks run in CI
As a follow-up to #135, it would be nice (and am assuming that it's not a deal-breaker) to also run the therapist checks during CI
The hardest part of the challenge here is similar what @peterbe encountered when trying Therapist on the main MDN codebase, re dependencies and container.
Question for @escattone or @peterbe if you have headspace:
To get therapist running in CI, it'll need to run inside the Docker containers (please shout if I'm wrong about that).
However, therapist (based on work for #135) requires both Python and JS/npm-universe dependencies to do it all. app doesn't contain npm, while static doesn't contain python
Before I over-think all this:
a) is this already a solved problem elsewhere in MDN? b) how much is linting-in-CI a must-have?
And if b) says we do have to have it, am wondering about:
- Add a shortcut to
therapist.ymlso that it's poss to just run the Python linting/autoformatting in theappcontainer - Add calls to the JS linting/autoformatting in the
staticcontainer directly, and doesn't bother usingtherapistthere at all (which is likely fine, astherapist's big win is local development and pre-commit checking)
I would say Therapist is great for your laptop work but not necessary in CI. However, it'd be nice to share the same config in your git hooks as you run on CI. But fundamentally, Therapist doesn't yet work WITHOUT git and you don't have git inside docker, do you?
However, I'd become a fan of disconnecting all this Black and Flake8 and Therapist/husky/precommit out of Docker. It's got nothing to do with runtime so it shouldn't be part of the Dockerfile's requirements.txt in any way. And if you run it entirely outside of Docker you're more free.
I think the stumbling block fo switching to Therapist in Kuma was that David (Flanagan) didn't like that people had to do things beyond just doing git clone GITURL && cd kuma && docker-compose build && ...
I'm less convinced because Docker sucks as a rapid development platform. The only good thing about docker is getting the runtime/CI/deployment versions perfectly matched.
Note that in TravisCI for kuma we run the JavaScript and the Python linting outside of Docker. The docker-compose and Docker building stuff takes minutes and it sucks to find out that your PR is going to fail, after 15 mins, because of a whitespace issue.
I don't think it's a tall order to "demand" that people who want to work on Kuma or dev portal has some version of Python3 and NodeJS on their laptop. After all, that's what we're expecting of Travis.
I'm most familiar with Therapist and honestly that plus the fact that I'm friends with its author is why I'm a Therapist fan-boy. Not necessarily because it's better. I do however love the fact that it's possible to share 1 config file for checking staged files as well as all files. And it's 1 config file to defined all the various linting configs such as JavaScript and Python.
We at IT are starting to use a tool call pre-commit perhaps that would be a better place to start?
See: https://pre-commit.com/
Our demo repo can be seen here: https://github.com/mozilla-it/it-demo/blob/master/.pre-commit-config.yaml
Hi Ed
Thanks for the suggestion! There was discussion of which way to go between pre-commit and therapist, but based on comparisons by me and @peterbe we went with Therapist, but there wasn't a lot of difference.
If we feel there's enough momentum behind pre-commit after a while, we can look to move, I guess. At least we have a robot in place, making life easier!
S