I tried following the docs for this repo, and added the following:

load("//:def.bzl", "shellcheck")

shellcheck(name = "shellcheck")

when i then tried to run with the following

$ bazel run //:shellcheck -- -x /path/to/my/sh/file

it ignores all of the arguments and always just prints the help

with the following BUILD:

load("//:def.bzl", "shellcheck")

shellcheck(name = "shellcheck_path")

sh_binary(
    name = "shellcheck",
    data = [":shellcheck_path"],
    srcs = ["run_shellcheck.sh"],
    args = [
        "$(location //:shellcheck_path)",
    ]
)

and a sh wrapper like so:

#!/bin/bash

SHELLCHECK_SCRIPT_PATH="${1}"
shift
SHELLCHECK_PATH="$(cat "$SHELLCHECK_SCRIPT_PATH")"

exec "$SHELLCHECK_PATH" "$@"

it works as expected

not sure if i am mis understanding/configuring something, and whether my hack is necessary

A feature request to close #14.

It would be neat if the README documented how to use this rule in a MODULE.bazel with bazel_dep, given #13.

Found this whilst trying to implement #9.

Expected behaviour: we can use shellcheck without needing to define anything else than shellcheck_deps.

Thank you for writing this! I'd been wondering if there was support for this (and shfmt come to that).

I have a .shellcheckrc in my repository root. It's not picked up; I validated this by adding --exclude=SC2086 to it and running against a file that violates that; that rule is still included.

I have copy/pasted to WORKSPACE and a BUILD file precisely as in README.md @ ceb47de.

Should I expect it to? My instinct is "not yet" as I don't see shellcheckrc appear in this repo.

Is there a way I can supply arguments to the underlying invocation of shellcheck, or a change I might patch in to have the rule look in the workspace-root for the config (as that's the most likely location)?

This needs upstream support via bazelbuild/bazel#18331

Hi! I noticed the MODULE.bazel but don't see any release in https://registry.bazel.build/all-modules could we get this added to the registry?

Semi-related to #14

This set of rules looks really promising! I was able to get it up and running easily, but I noticed there doesn't seem to be any way to pass arguments to shellcheck, which can be useful for a variety of reasons:

• --color= argument
• --include / --exclude to control which lints are run
• --format= for alternative output formats

Would you consider exposing an args=[] parameter on the main rule for these purposes? I can probably work around it by defining my own rule in the meantime, but this seems like something that others would probably find useful as well.

A release that incorporates #19 would allow folks to remove any custom patches they have upgrading the version.

Aside, it might be worth considering allowing end users to configure there own versions or download paths.
Examples:

• rules_js
• rules_go go_register_toolchains
• rules_go go_download_sdk

More than happy to help!

I frequently get openBinaryFile: does not exist (No such file or directory) error from this rule - for bash script files which clearly do exist!

I suspect it may be due to some Bazel concurrency issue, or something like that.

Using v0.1.1 on Bazel 6.0.0.

shellcheck_test(
    name = "shellcheck_test",
    size = "small",
    data = glob(
        [
            "**/*.bash",
            "**/*.sh",
        ],
        exclude = [
            "**/bazel-bin/**",
            "**/bazel-out/**",
            "site/**",
            ".venv/**",
        ],
    ),
    tags = ["lint"],
)

will regularly fail with something like this:

$ bazelisk test //...
INFO: Analyzed 15 targets (9 packages loaded, 34 targets configured).
INFO: Found 10 targets and 5 test targets...
INFO: From Testing //:shellcheck_test:
==================== Test output for //:shellcheck_test:
bazel-enola/tools/git/install-hooks.bash: bazel-enola/tools/git/install-hooks.bash: openBinaryFile: does not exist (No such file or directory)
================================================================================
INFO: Elapsed time: 0.623s, Critical Path: 0.08s
INFO: 5 processes: 3 internal, 2 linux-sandbox.
INFO: Build completed, 1 test FAILED, 5 total actions
//connectors/demo:src/test/java/dev/enola/demo/ModelTest        (cached) PASSED in 0.6s
//core/lib:src/test/java/dev/enola/core/IDsTest                 (cached) PASSED in 0.8s
//core/proto:core_buf_proto_lint                                (cached) PASSED in 0.0s
//tools/proto:src/test/java/dev/enola/tools/proto/TextProtoValidatorTest (cached) PASSED in 0.7s
//:shellcheck_test                                                       FAILED in 0.1s
  /home/vorburger/.cache/bazel/_bazel_vorburger/8278ca71b7724cd0429873b01f58f5d3/execroot/_main/bazel-out/k8-fastbuild/testlogs/shellcheck_test/test.log

Executed 1 out of 5 tests: 4 tests pass and 1 fails locally.

Re-running Bazel makes it go away. Which one shouldn't have to do, of course.