fix pre-commit issues, add pre-commit CI job for PRs

[jameslamb]

Working on #38, I noticed that this repo has a pre-commit config but that the code isn't actually passing those checks.

This PR proposes:

• updating all the hooks (pre-commit autoupdate)
• adding the RAPIDS copyright hook
• limiting ruff to a specific subset of checks
  • (instead of ALL, which is very noisy and sometimes has conflicts)
• fixing all the issues reported by pre-commit
• adding a CI job that runs on PRs to check this

Notes for Reviewers

Any cosmetic changes were made automatically by pre-commit run --all-files.

Why add a CI job?

This repo now contains some non-trivial code (not just GitHub Actions configs). For example:

• https://github.com/rapidsai/shared-actions/blob/aaee5cb4c3a74ee4978e43817664a94ab6fd66a2/check_nightly_success/check-nightly-success/check.py
• https://github.com/rapidsai/shared-actions/tree/aaee5cb4c3a74ee4978e43817664a94ab6fd66a2/telemetry-impls

I think the small cost of a CI job on every PR is worth it in exchange for improved release confidence in changes to that code.

[jameslamb]

@raydouglass if you agree with the spirit of this PR, could you also make the pr workflow's checks job required for merging PRs?

[KyleFromNVIDIA]

Approved with one point of discussion for other repos.

[KyleFromNVIDIA]

Don't most of our repos just run pre-commit directly in their ci/check_style.sh script? I'm wondering if we can somehow integrate this into shared-workflows and reduce duplication.

[jameslamb]

Yeah, many of the repos end up having a check_style.sh that does this:

• set up a conda environment (which almost always just has pre-commit in it)
• run pre-commit run --all-files

For those cases, just using the pre-commit action like this would be faster and simpler, I think. pre-commit already manages creating a venv with the dependencies, and that action comes with some across-multiple-runs caching built in.

HOWEVER... some repos do other stuff in check_style.sh.

For example, a couple download cmake-format files like this:

https://github.com/rapidsai/cudf/blob/bbf4f7824c23c0c482f52bafdf1ece1213da2f65/ci/check_style.sh#L21-L24

The pattern of running a ci/check_style.sh is there to enable those per-repo types of customizations, I think.

[jameslamb]

I'm wondering if we can somehow integrate this into shared-workflows and reduce duplication.

Also worth noting... for this particular PR, I wouldn't want to introduce a shared-workflows dependency here. That'd create a circular dependency between shared-workflows and this repo, and I'm not sure what the implications of that would be.