[yolani]

Share lint tooling and enforce ruff and buildifier checks
Make the ruff and buildifier setup reproducible across VS Code, the git
hooks and CI, and surface findings as GitHub code scanning alerts.

Editor:

• Share the .vscode settings and extension recommendations: bundled
  ruff as Python formatter, Pylance search paths for the Bazel pip and
  protobuf repositories, and buildifier via tools/buildifier, a wrapper
  around the hermetic Bazel binary.

Lint configuration:

• Enable the ruff rules I, UP and SIM on top of the defaults and mark
  score as first-party so import sorting matches the Bazel lint aspect.
• Fix all existing ruff and buildifier findings, including loading
  proto_library/ProtoInfo from @com_google_protobuf and adding the
  missing rules_shell dependency.

Git hooks:

• Add a pre-commit hook running ruff check/format and buildifier
  (formatting plus all lint warnings) with the repository config.
  Install it with bazel run //:install_hooks.
• Drop the ruff.check/ruff.fix wrapper targets in favour of the hook.

CI:

• Run buildifier recursively in its own linter job and convert its
  findings to SARIF, pointing formatting findings at the changed lines.
• Gate ruff with the aspect lint "hard" strategy, add the missing rule
  IDs to its SARIF and upload both reports to code scanning.
• Fail the SARIF merge step with a clear error if the lint build did
  not produce a build event file.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[LittleHuba]

I would change the mode here. This script should be run through bazel.
Currently you loose hermeticity here. E.g. the script assumes that jq is available on host.
I would recommend, that you create an aspect for rules_lint that uses buildifier and generates the sarif report per call. Then you have the exact infrastructure that we have for all other linters.

[yolani]

Unfortunatly i explicitly did this on purpose... The buildifier aspect only visits bzl_library targets by default, other BUILD or .*bzl files have to be explicitly put in filegroups with certain tags, see here. That means i would have to create one filegroup per bazel package (about 30 already just for this small repo) and also maintain them.
I would rather delete the sarif conversion. It's a comfort feature anyway, also without the report injected into code scanning the buildifier check itself will work.
What i can do is add an additional stap in the workflow to make sure the required commandline tools are there.

[LittleHuba]

Accepting this with the known open conversation for buildifier not running through rules_lint.
There is currently no immediate better way. We agreed to look into a rules-lint native way in a follow-up.