Introduce autoformatting bot #5065
Conversation
lint.sh
Outdated
| How to apply black formatting: | ||
| 1. Run `pip install $(cat dev/lint-requirements.txt | grep "black==") && black .` | ||
| 2. Comment `/autoformat` on the PR' |
There was a problem hiding this comment.
| How to apply black formatting: | |
| 1. Run `pip install $(cat dev/lint-requirements.txt | grep "black==") && black .` | |
| 2. Comment `/autoformat` on the PR' | |
| To apply black formatting, do one of the following: | |
| 1. Run `pip install $(cat dev/lint-requirements.txt | grep "black==") && black .` | |
| 2. Comment `/autoformat` on the PR' |
.github/workflows/autoformat.yml
Outdated
| # As mentioned in the doc below, if we use `secrets.GITHUB_TOKEN`, a commit cerated by | ||
| # this workflow will not trigger other GitHub Actions workflows: | ||
| # https://docs.github.com/en/actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow | ||
| # To make it work, register a personal access token for the mlflow-automation bot as |
There was a problem hiding this comment.
Should we add these steps to the CONTRIBUTING guidelines?
There was a problem hiding this comment.
For someone who wants to run this workflow on their fork?
There was a problem hiding this comment.
I'm not sure if there are any regular contributors who do this? I suppose if they are they're going to be reading over the Actions yaml configs when they set it up though.
| id: check-diff | ||
| run: | | ||
| has_diff=$([[ -z "$(git diff)" ]] && echo "false" || echo "true") | ||
| echo "::set-output name=has_diff::$has_diff" |
There was a problem hiding this comment.
Did you want to include pylint checks from the repo's pylintrc for only the diff files as well to fast-fail since full linting checks take quite a bit of time to run?
There was a problem hiding this comment.
Thanks for the comment! The role of this bot is to fix something auto-fixable, pylint errors are (usually) not auto-fixable.
There was a problem hiding this comment.
With the local commit hook, I guess that would be redundant (you have to fix lint issues on diffs before a commit occurs anyway). This makes perfect sense to leave it solely up to black for automated adjustments.
harupy
force-pushed
the
autoformatting
branch
from
ad79794
to
9c10e8c
Compare
Signed-off-by: harupy <hkawamura0130@gmail.com>
harupy
force-pushed
the
autoformatting
branch
from
47f7ca2
to
c7720a1
Compare
| run: | | ||
| npm i | ||
| - run: | | ||
| npm run lint:fix |
There was a problem hiding this comment.
this is calling .eslintrc.js settings as defined in package.json operating solely on mlflow.server.js.src, right? So we're only looking at .js, .jsx, .ts, .tsx modules in src?
I'm likely completely wrong about this, but does jest's "collectCoverageFrom" apply to the lint:fix script execution to restrict auto-formatting lint corrections based on jest, or does it need to be explicitly defined in the lint:fix script config e.g., "lint:fix": "eslint src --fix --ext .js,.jsx,.ts,.tsx"?
There was a problem hiding this comment.
we're only looking at .js, .jsx, .ts, .tsx modules in src?
Yes.
does jest's "collectCoverageFrom" apply to the lint:fix script execution
No, it doesn't.
|
LGTM |
Signed-off-by: harupy hkawamura0130@gmail.com
What changes are proposed in this pull request?
As the PR title describes, introduce an autoformatting bot. Note this bot only fixes auto-fixable errors (e.g. black errors).
How is this patch tested?
Tested using a PR on my fork: harupy/test-auto-format#8
Does this PR change the documentation?
ci/circleci: build_doccheck. If it's successful, proceed to thenext step, otherwise fix it.
Detailson the right to open the job page of CircleCI.Artifactstab.docs/build/html/index.html.Release Notes
Is this a user-facing change?
(Details in 1-2 sentences. You can just refer to another PR with a description if this PR is part of a larger change.)
What component(s), interfaces, languages, and integrations does this PR affect?
Components
area/artifacts: Artifact stores and artifact loggingarea/build: Build and test infrastructure for MLflowarea/docs: MLflow documentation pagesarea/examples: Example codearea/model-registry: Model Registry service, APIs, and the fluent client calls for Model Registryarea/models: MLmodel format, model serialization/deserialization, flavorsarea/projects: MLproject format, project running backendsarea/scoring: MLflow Model server, model deployment tools, Spark UDFsarea/server-infra: MLflow Tracking server backendarea/tracking: Tracking Service, tracking client APIs, autologgingInterface
area/uiux: Front-end, user experience, plotting, JavaScript, JavaScript dev serverarea/docker: Docker use across MLflow's components, such as MLflow Projects and MLflow Modelsarea/sqlalchemy: Use of SQLAlchemy in the Tracking Service or Model Registryarea/windows: Windows supportLanguage
language/r: R APIs and clientslanguage/java: Java APIs and clientslanguage/new: Proposals for new client languagesIntegrations
integrations/azure: Azure and Azure ML integrationsintegrations/sagemaker: SageMaker integrationsintegrations/databricks: Databricks integrationsHow should the PR be classified in the release notes? Choose one:
rn/breaking-change- The PR will be mentioned in the "Breaking Changes" sectionrn/none- No description will be included. The PR will be mentioned only by the PR number in the "Small Bugfixes and Documentation Updates" sectionrn/feature- A new user-facing feature worth mentioning in the release notesrn/bug-fix- A user-facing bug fix worth mentioning in the release notesrn/documentation- A user-facing documentation change worth mentioning in the release notes