scikit-learn / scikit-learn/scikit-learn
Reuse the `pre-commit` linter config in the CI runners
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 67.3k
- Forks
- 27.4k
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 58
Description
At the moment, our CI runs linting jobs using a custom script build_tools/lintin.sh with manually pip installed dependencies in the Circle CI and Azure Pipelines CI configuration files.
Those linter tool versions are not always consistent with what we configure in .pre-commit-config.yaml and that can cause problems such as the following: https://github.com/scikit-learn/scikit-learn/pull/32499#issuecomment-3402244557.
I think we should refactor our CI config to reuse the pre-commit command, for instance by running:
pre-commit run --all-files
Instead of our custom build_tools/linting.sh script. However, this might not be that easy:
- there are probably linting failures to fix or config to update to ignore specific files or folders;
- there might be CI integration to update, in particular the
.github/workflows/bot-lint-comment.ymland the./build_tools/get_comment.pyscript that generate a helpful user facing comments will need to be reworked and adapted to work with the output of thepre-commitcommand.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by comparing the linting steps in the Circle CI and Azure Pipelines configuration files with .pre-commit-config.yaml and build_tools/linting.sh. Then inspect .github/workflows/bot-lint-comment.yml and build_tools/get_comment.py to understand how lint output is reported. Done means CI reuses the pre-commit configuration consistently, required lint failures or exclusions are addressed, and user-facing comments still work.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- ci-cd, tooling
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100