Feature Request: Migrate Buildifier to Bazel Lint Umbrella

[oharboe]

If we agree on this, then we can convert this into PR at a click of a button.

Description

Buildifier (format + lint for BUILD, .bzl, and MODULE.bazel files) currently
runs as a standalone GitHub Actions workflow
(.github/workflows/buildifier.yaml) that downloads its own binary and
caches it independently. This should be migrated to the Bazel lint umbrella
(//:lint_test and //:fix_lint) for consistency with how TCL linting
already works.

Current state

The GitHub Actions workflow does two things:

# Format check
./buildifier -r -mode=check -lint=off .

# Lint check
./buildifier -r -lint=warn .

The tool version (v8.2.1) is pinned in the workflow YAML, not in Bazel's
dependency management. A .buildifier.json config already exists at the
repo root.

Problem

1. Cannot run locally — developers must push and wait for CI to discover
   buildifier violations. This violates
   POLA:
   bazelisk run //:fix_lint should fix everything it can and report the
   rest, but currently it knows nothing about BUILD files.

2. Version drift — the buildifier version is pinned in GitHub Actions
   YAML, separate from Bazel's hermetic dependency management
   (bazel/requirements.in, MODULE.bazel). It can drift out of sync
   with what developers run locally (if they run it at all).

3. Inconsistent pattern — TCL linting already uses the Bazel lint
   umbrella. Every additional language that stays outside the umbrella is
   a special case that new contributors have to discover separately.

Proposed targets

Per the naming convention:

Target	What it does
//:lint_bzl_test	buildifier -r -mode=check -lint=warn . (read-only)
//:fmt_bzl_test	buildifier -r -mode=check -lint=off . (format only)
//:tidy_bzl	buildifier -r -mode=fix -lint=fix . (auto-fix)

Wire into umbrellas:

• Add lint_bzl_test and fmt_bzl_test to //:lint_test
• Add buildifier fix step to bazel/fix_lint.sh

Suggested Solution

1. Add buildifier as a Bazel-managed tool dependency (it's already available
   as a @buildifier Bazel module)
2. Create bazel/bzl_lint_test.sh, bazel/bzl_fmt_test.sh, bazel/bzl_tidy.sh
   following the same pattern as bazel/tcl_lint_test.sh etc.
3. Add sh_test / sh_binary targets in BUILD.bazel
4. Wire into //:lint_test and bazel/fix_lint.sh
5. Once validated, retire .github/workflows/buildifier.yaml

The .buildifier.json config (mode: fix, lint: fix, warnings: all)
already exists and can be reused by the new scripts.

Additional Context

• Bazel Lint Targets — umbrella framework and naming convention
• Shell Script Conventions — idiom for new wrapper scripts
• .github/workflows/buildifier.yaml — current CI workflow to be retired
• .buildifier.json — existing buildifier config

Suggested Solution

No response

Additional Context

No response

[oharboe]

@hzeller Thoughts?

[Divinesoumyadip]

Hi @oharboe , this aligns perfectly with the recent work I did on the hermetic:tidy target and Bazel test parity. I'd love to take this on and migrate Buildifier into the Bazel Lint umbrella using the bzl_lint_test.sh and bzl_fmt_test.sh pattern you outlined. Could you assign this to me?

[oharboe]

Thanks @Divinesoumyadip !

@maliberty actually assigns issues, but as this is a point of friction and frustration day to day for contributors, I suspect that whatever PR that is finished first to board up the broken windows safely will be merged, from which further improvements will be much appreciated!

[hzeller]

I feel kinda neutral about this. Bulidifier is essentially stable so there is not much issue with version skew w.r.t. formatting anyway, and every developer using bazel has bazel-buildtools in their shell.nix anyway.

What is more annoying is clang-format, which has slight version skews even between minor versions. It would be good to use a standardized form, but unfortunately, clang-format is not shipped with the llvm_toolchain we pull (luckily, clang-tidy is).

The main issues with these linters and formatters is, I think if they run within bazel, they can't modify the code itself if they have a change to apply, so the user would need to be prompted to run some manual script anyway.

[oharboe]

I find myself wasting CI time and being frustrated at not having a "fix_lint" that just fixes everything, bazel specifically gives me grief for reasons I don't understand.

Check this outhttps://github.com//pull/9856, fixes source files just fine! 😌

[Divinesoumyadip]

Hi @oharboe, I've opened a PR that addresses exactly this , bazelisk run //:fix_lint now runs both tidy_bzl and tidy_tcl, so it fixes Starlark and TCL files in one command. The old GitHub Actions workflow has been retired and both fmt_bzl_test and lint_bzl_test are wired into //:lint_test.