keith / buildifier-prebuilt Goto Github PK

Be able to do the following:

buildifier(
    name = "buildifier.check",
    exclude_patterns = _BUILDIFIER_EXCLUDE_PATTERNS,
    lint_mode = "warn",
    lint_warnings = [
        "all",
        "-cc-native",
    ],
    mode = "diff",
)

If you specify this today, you get the following error:

buildifier: warning categories with modifiers ("+" or "-") can't be mixed with raw warning categories

I implemented some Bazel rules (bzlrelease) that work with a GitHub Actions workflow to create releases for my Bazel rule repositories. In short, it generates the release notes along with a workspace snippet, creates the GitHub release, and creates an auto-merge PR to update the README.md with the latest workspace snippet.

All of the pre-requisites are already being loaded in this repository. I would add a release Bazel package that would contain a BUILD file, README.md file, and a workspace snippet template (i.e., contains the load statements that need to be added to client workspaces). I would update the repository's README.md to include two markers as markdown comments to indicate where to insert/replace the generated workspace snippet. Releases can be created using a Bazel run command or via the GitHub Actions web interface.

If you would like to see an actual implementation, here is the release package, the GitHub Actions workflow and a release generated by this process for cgrindel/bazel-starlib. I could add this pretty quickly if you are interested.

Steps to reproduce

$ echo 7.0.0 > .bazelversion
$ echo 'bazel_dep(name = "buildifier_prebuilt", version = "6.4.0", dev_dependency = True)' > MODULE.bazel
$ bazelisk query '@buildifier_prebuilt//...'

Expected behavior
List of targets

Actual behavior

ERROR:
error loading package under directory '':
error loading package '@@buildifier_prebuilt~6.4.0//release':
Unable to find package for @@[unknown repo 'cgrindel_bazel_starlib' requested from @@buildifier_prebuilt~6.4.0]//bzlrelease:defs.bzl:
The repository '@@[unknown repo 'cgrindel_bazel_starlib' requested from @@buildifier_prebuilt~6.4.0]' could not be resolved:
No repository visible as '@cgrindel_bazel_starlib' from repository '@@buildifier_prebuilt~6.4.0'.

(Line breaks added after colon to make it easier to read, but it's all on one line really.)

@ b02049d

$ bazel test //tests/tools_tests:generate_assets_declaration_test --test_output=errors
INFO: Analyzed target //tests/tools_tests:generate_assets_declaration_test (2 packages loaded, 10 targets configured).
INFO: Found 1 test target...
FAIL: //tests/tools_tests:generate_assets_declaration_test (see /home/jamison/.cache/bazel/_bazel_jamison/04f084c324ba0be0b9506e8091939f14/execroot/buildifier_prebuilt/bazel-out/k8-fastbuild/testlogs/tests/tools_tests/generate_assets_declaration_test/test.log)
INFO: From Testing //tests/tools_tests:generate_assets_declaration_test:
==================== Test output for //tests/tools_tests:generate_assets_declaration_test:
which: no gh in (.:/bin:/usr/bin:/usr/local/bin)
Could not find Github CLI (gh).
================================================================================
Target //tests/tools_tests:generate_assets_declaration_test up-to-date:
  bazel-bin/tests/tools_tests/generate_assets_declaration_test
INFO: Elapsed time: 0.134s, Critical Path: 0.04s
INFO: 2 processes: 2 linux-sandbox.
INFO: Build completed, 1 test FAILED, 2 total actions
//tests/tools_tests:generate_assets_declaration_test                     FAILED in 0.0s
  /home/jamison/.cache/bazel/_bazel_jamison/04f084c324ba0be0b9506e8091939f14/execroot/buildifier_prebuilt/bazel-out/k8-fastbuild/testlogs/tests/tools_tests/generate_assets_declaration_test/test.log

INFO: Build completed, 1 test FAILED, 2 total actions

I think that we are ready to create a release with the new code. Would you like to do the honors? I am happy to kick it off. I just need to know what version number you would like to use.

Due to no windows toolchain existing? I think it should at least build even if it fails to run, otherwise it must be marked as manual to avoid even building it by default (but then it's of course manual for all platforms).

Ideally something such as target_compatible_with should be used, however that doesn't stop the toolchains from being downloaded so won't work with the usage of toolchains like today (6.1.0).

Thanks for the work on this project! It's so great but I'm encountering an issue blocking me to continue with it.

Issue:

• When enabling build --nolegacy_external_runfiles, buildifier-prebuilt still looks for external/buildifier_darwin_arm64/file/buildifier

Reproduction:

1. Have a simple Bazel WorkSpace, the following steps will take this one from rules_python as the example
2. Change WORKSPACE lines 64-72 as instructions in line 63
3. Integrate buildifier-prebuilt with the legacy-workspace-file method
4. Create a rule for running buildifier
5. Run "bazel run //:buildifier.check". it works.
6. Choose one of the below two steps to operate:
   6-1. Add build --nolegacy_external_runfiles into the file .bazelrc; I added it in the first line. Then run bazel run //:buildifier.check agan.
   or
   6-2. Run "bazel run //:buildifier.check --nolegacy_external_runfiles"
7. It does not work (no fixes found) now.
8. (Optional) Add arguments --run_under="bash -x" and --sandbox_debug and run again for more details.

Expectation:

• buildifier-prebuilt do compatible with build --nolegacy_external_runfiles

The rule here has diverged a bit from buildtools, namely that buildtools wraps the "diff" mode in a test rule useful for CI checks

https://github.com/bazelbuild/buildtools/blob/master/buildifier/buildifier.bzl#L37-L41

I was going to adopt this prebuilt strategy and clean up our WORKSPACE a bit, but hit a snag in that small difference.

Checking here if matching the rules in the buildtools source is a goal, and if so I'll open a patch.

The only reason this repo uses toolchains is to avoid downloading multiple versions of buildifier that you'll never use on your platform. It looks like if you use some indirection with a bazel alias in a select() you can avoid this as well. bazelbuild/bazel@903c272

If someone can confirm this is intentional behavior I can switch to this method instead to remove a lot of boilerplate.

First, thanks for putting this repository together. I want to remove the requirement to build buildifier for repositories that use bzlformat. Your solution looks great. However, I wonder if you would be open to a PR that allows the client for this repository to specify the version and, optionally, the sha256 values? If so, I will put one together and send it over for review.

The current README.md states that the following should work:

bazel run -- @buildifier_prebuilt//:buildozer ARGS

However, this will not work correctly. Bazel will execute the command in a sandbox, not the workspace. Hence, buildozer will never find any of the paths.

A possible fix would be to provide a shell script that performs a cd "${BUILD_WORKSPACE_DIRECTORY}" and then executes the buildozer commands.

NOTE: The buildifier would also benefit from this technique as today one must specify absolute paths for buildifier to find files and directories.