GH-46528: [CI][Dev] Remove "archery lint"#46686
Conversation
ci/scripts/install_iwyu.sh
Outdated
There was a problem hiding this comment.
We'll revisit IWYU in the future.
It's tracked by #46543 .
cpp/build-support/run_clang_tidy.py
Outdated
There was a problem hiding this comment.
We'll revisit clang-tidy in the future.
It's tracked by #46542 .
There was a problem hiding this comment.
pre-commit installs pined clang-format automatically.
r/vignettes/developers/workflow.Rmd
Outdated
There was a problem hiding this comment.
We'll use Air in the future.
It's tracked by #46592 .
|
Good catch! We should remove them. I'll do it. |
|
That's fine with me. @kszucs Any comments? |
r/vignettes/developers/workflow.Rmd
Outdated
There was a problem hiding this comment.
Thanks for making this all a lot more concise!
We should leave in information about how to run it other than with pre-commit. Many R users are more comfortable with running lintr directly as it's much simpler (I've personally had issues getting pre-commit set up so won't be the only one), so it'd be great to give them both options.
There was a problem hiding this comment.
OK.
Is it OK that running r/tools/lint.R for non pre-commit option? R developers need to install lintr manually with this approach.
(Can we remove ci/docker/linux-apt-lint.dockerfile? I want to remove ci/docker/linux-apt-lint.dockerfile.)
There was a problem hiding this comment.
Or is running lintr::lint_package("arrow/r") directly better?
There was a problem hiding this comment.
Running lintr::lint_package("arrow/r") is better for a non-pre-commit option, yes. arrow/r/lint.R could possibly be removed once it's unhooked from CI. The average R contributor will probably run lintr::lint_package to lint and the core dev team generally runs arrow/r/lint.sh to lint R and C++ at the same time.
I'm not sure we can remove linux-apt-lint.dockerfile just yet. IIRC the way that's set up, it will catch lints in the R packages internal C++ code but the current r.yml workflow just lints the R code so removing linux-apt-lint.dockerfile could cause us to merge R C++ code with lint issues. I think we could modify the R workflow to keep the functionality though. Happy to work on that.
There was a problem hiding this comment.
OK. Let's use lintr::lint_package("arrow/r").
the core dev team generally runs
arrow/r/lint.shto lint R and C++ at the same time.
Hmm... This PR removes r/lint.sh...
Could you share pre-commit related issues you got? Can we fix them instead of avoiding pre-commit?
I'm not sure we can remove linux-apt-lint.dockerfile just yet. IIRC the way that's set up, it will catch lints in the R packages internal C++ code but the current
r.ymlworkflow just lints the R code so removing linux-apt-lint.dockerfile could cause us to merge R C++ code with lint issues. I think we could modify the R workflow to keep the functionality though.
Oh, I missed that the r.yml workflow also runs lintr:
Lines 334 to 351 in b630f48
(BTW, I didn't know that lintr::expect_lint_free() exists. I changed the pre-commit configuration to use lintr::expect_lint_free() and removes r/tools/lint.R.)
I want to remove the "Run lintr" step too because it's already done by pre-commit
arrow/.github/workflows/dev.yml
Lines 66 to 68 in b630f48
archery lint arrow/.github/workflows/dev.yml
Lines 71 to 78 in b630f48
And pre-commit and archery lint check not only R code but also R C++ code. So we will not merge R C++ code with lint issues.
There was a problem hiding this comment.
Thanks. You're using Ubuntu 22.04, right?
How about the following?
diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index c3835ac0f1..e3e8abdeed 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -356,7 +356,10 @@ repos:
?^swift/gen-protobuffers\.sh$|
)
- repo: https://github.com/scop/pre-commit-shfmt
- rev: v3.11.0-1
+ # v3.11.0-1 or later requires pre-commit 3.2.0 or later but Ubuntu
+ # 22.04 ships pre-commit 2.17.0. We can use update this rev after
+ # Ubuntu 22.04 reached EOL (June 2027).
+ rev: v3.10.0-1
hooks:
- id: shfmt
alias: shellI've opened #46798 for this.
There was a problem hiding this comment.
FYI: You can use pre-commit run --all-files r only for R as described in the changed document.
In the case, shfmt isn't used. So the error isn't occurred.
There was a problem hiding this comment.
I feel like I did get some error when I ran the full command but can't recall now as I've just updated pre-commit. Thanks @kou! :)
|
We have duplicated most of the linters in both archery and pre-commit hooks also causing version and configuration mismatches for certain tools, so I strongly support this change. |
We can use pre-commit instead of "archery lint".
Co-authored-by: Bryce Mecum <petridish@gmail.com>
69ef60a to
478eb89
Compare
|
I'll merge this in a few days if nobody objects it. |
|
After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit c314e80. There were 73 benchmark results with an error:
There were no benchmark performance regressions. 🎉 The full Conbench report has more details. It also includes information about 2 possible false positives for unstable benchmarks that are known to sometimes produce them. |
### Rationale for this change We can use pre-commit instead of "archery lint" for all linters/formatters. ### What changes are included in this PR? * Remove "archery lint" CI job * Remove "archery lint" related codes including IWYU and clang-tidy because IWYU and clang-tidy aren't used for now * Remove "archery lint" related docs including IWYU and clang-tidy related docs ### Are these changes tested? Yes. ### Are there any user-facing changes? No. It's only affected to developers. * GitHub Issue: apache#46528 Lead-authored-by: Sutou Kouhei <kou@clear-code.com> Co-authored-by: Sutou Kouhei <kou@cozmixng.org> Co-authored-by: Bryce Mecum <petridish@gmail.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>
Rationale for this change
We can use pre-commit instead of "archery lint" for all linters/formatters.
What changes are included in this PR?
Are these changes tested?
Yes.
Are there any user-facing changes?
No.
It's only affected to developers.