readthedocs / website

The Read the Docs community website
15 stars 5 forks source link

Setup `pre-commit` on this project #267

Open humitos opened 4 months ago

humitos commented 4 months ago

We should configure pre-commit on this project to call all the validations that are happening on CircleCI and avoid unexpected failures after pushing the code to GitHub.

humitos commented 3 months ago

I jumped into this today and I found it's going to be pretty complex to setup this, and maybe a little tedious. Mainly because on CircleCI we are performing a check over the HTML output generated by Pelican.

https://github.com/readthedocs/website/blob/main/.circleci/config.yml#L34

So, we will need to build the site on pre-commit to be able to replicate that locally, which seems a big overhead added. We would need to install dependencies via Poetry as well, and more complex things.

Unfortunately, I think there is no easy answer here and it may makes sense to de-prioritize this task for now, since it won't have too much impact anyways.

The other checks are more related to the custom Pelican theme we have here, which we are not touching frequently --so, it's probably fine to skip them for now.

agjohnson commented 3 months ago

Are there any specific pre-commit checks we wanted? I would agree this doesn't seem super valuable at the moment with all the current linting/checks providing a good amount of value already.

humitos commented 3 months ago

Are there any specific pre-commit checks we wanted?

The one that I want is npx html-validate --formatter codeframe output/ which is the hardest to setup (requires building the site with Pelican + poetry), and the one why I stopped this work 😄 . Most of the other pre-commit checks we could add are not super relevant.

agjohnson commented 3 months ago

Yeah that makes sense.

I think I might have thought you were implying somewhere that we have existing pre-commit checks in common/etc that would be applicable in this repo. Adding pre-commit would be nice, but this is mostly used when editing HTML too, so less frequent than blog posts/markdown at least. I'd agree it would be nice but not a strong priority.