I'm migrating from 0.2.0 (which didn't include the persistent worker) to the latest HEAD (ebc7cc6), and everything works fine... Unless I go above the threshold defined in Detekt's config file. The reports then fail to build (as expected), but I don't get any useful output:

bazel build //java/fr/enoent/fs:file_watcher_detekt_report
INFO: Invocation ID: b4f6729f-50da-4230-979a-9c3e6d9cf911
INFO: Build option --action_env has changed, discarding analysis cache.
INFO: Analyzed target //java/fr/enoent/fs:file_watcher_detekt_report (4 packages loaded, 1907 targets configured).
INFO: Found 1 target...
ERROR: /home/kernald/dev/esp-media-remote/java/fr/enoent/fs/BUILD:3:1: Detekt java/fr/enoent/fs/file_watcher_detekt_report_detekt_report.txt failed (Exit 1)
io.gitlab.arturbosch.detekt.cli.BuildFailure: Build failed with 1 weighted issues (threshold defined was 0).
Target //java/fr/enoent/fs:file_watcher_detekt_report failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 1.068s, Critical Path: 0.15s
INFO: 0 processes.
FAILED: Build did NOT complete successfully

Interestingly enough, setting --spawn_strategy=local or --spawn_strategy=worker doesn't make any difference.

We are currently using release bffa68b4948aa26153185f4feda278557dc01951 and Detekt 1.13.1

(18:22:04) INFO: From Compiling Kotlin to JVM @rules_detekt//detekt/wrapper:lib { kt: 9, java: 0, srcjars: 0 } [for host]:
--
  | external/rules_detekt/detekt/wrapper/src/main/kotlin/io/buildfoundation/bazel/detekt/execute/Detekt.kt:13:13: warning: 'buildRunner(Array<String>, PrintStream, PrintStream): Executable' is deprecated. Don't build a runner yourself.
  | buildRunner(args, outputPrinter, errorPrinter).execute()
  | ^
  | external/rules_detekt/detekt/wrapper/src/main/kotlin/io/buildfoundation/bazel/detekt/execute/Detekt.kt:13:13: warning: 'buildRunner(Array<String>, PrintStream, PrintStream): Executable' is deprecated. Don't build a runner yourself.
  | buildRunner(args, outputPrinter, errorPrinter).execute()
  | ^

--build-upon-default-config allows to override specific parts of the default configuration file, which sounds like a good place to start iterating on one's own config file.

Hello 👋

Issue related to #74.

I'm looking to deal with Detekt formatting. While looking here it appear we need to add a Gradle task or passing the io.gitlab.arturbosch.detekt:detekt-formatting jar into the plugins parameter while invoking Detekt.

While looking here it looks like this project doesn't support passing plugins options.

I'll keeping investigation and may create a PR with the additional feature and doc to add Ktlint formatting. But I don't have the workload actually.

Thanks,

Tested using Detekt 1.13.x and 1.14.x using release bffa68b4948aa26153185f4feda278557dc01951

(18:28:38) ERROR: /build/instant-features/formbuilder/safety-net-action/BUILD:3:21: Detekt instant-features/formbuilder/safety-net-action/lib_detekt_detekt_report.txt failed: Worker process did not return a WorkResponse:

This is our toolchain setup

load("@rules_detekt//detekt:toolchains.bzl", "rules_detekt_toolchains")

rules_detekt_toolchains(detekt_version = "1.13.1")

Currently it prints too much to stdout and I don't see an easy way to suppress this with Bazel ctx.actions.run api https://docs.bazel.build/versions/master/skylark/lib/actions.html#run

Bazel supports not only workers but multiplex workers as well. Funny enough — regular workers don’t have specs while multiplex ones do.

Seems like we’ll need execute multiple work requests in parallel, form responses and then send them atomically to the standard output. Sounds like a good task for RxJava! @artem-zinnatullin, your dreams of reactive Bazel rules might come true after all.

Currently each Detekt target will run jvm when executed, we should look into Persistent Worker/Daemon support to optimize this.

Hi all, again! I'm investigating slow Bazel builds on our CI, tracing suggests that rules_detekt consumes about 25 seconds (!) during Bazel query we don't even have any rules_detektbuild action in the build graph nor build graph at all — justbazel query`.

It seems like it happens because rules_detekt dependencies that we pull via rules_jvm_external are not pinned so that users could override versions I guess, but without pinning we never cache them properly.

We should be able to come up either with a fix in rules_detekt or an instruction on workarounding this similar to https://blog.aspect.dev/avoid-eager-fetches

Seems like we’ll need to do this via toolchains (take a look at the scala_toolchain for a good example).

Doing it via rule attributes is possible as well but I think it doesn’t work well with the workers workflow. With workers the process is started one-time and then consumes arguments from the standard input. Since we don’t invoke Detekt in a separate process but rather in the worker one (as part of the shared JVM classpath), we essentially provide JVM options one-time as well. If options are passed as rule attributes, only the first target attributes will be used, consecutive ones will be ignored.

Hello 👋

I would like to avoid copying the detekt config inside all of my BUILD files. Maybe, something like this

/BUILD

load("@rules_detekt//detekt:defs.bzl", "detekt")

detekt(
    name = "detekt",
    srcs = glob(["**/*.kt"]),
    parallel = True,
    disable_default_rulesets = True,
    cfgs = [
        "//:detekt.yml"
    ]
)

exports_files(["detekt.yml", "licence.template"])

And when running bazel build //:detekt it works for all my sub-projects. Do you have an idea on how I can achieve that ?

Thanks,

We have following effective bazelrc config on CI (kept only relevant options):

build --remote_cache=somerealcacheserver --remote_upload_local_results=true

Yet we're seeing almost no cache hits for rules_detekt actions.
Our Buck detekt builds with exact same srcs and detekt config are getting up to 100% cache hits.

Other types of Bazel actions are getting proper cache hits in our setup, I'm trying to figure out where the problem is coming from but so far can't tell so I'm filing this issue.

To allow user-specific updates and or forks of Detekt.

This is easy to support as is, but API might change with Persistent Worker support #7 due to potential changes in classloading/etc, thus it's on hold

Building rules_detekt 0.4.0 raises a warning:

external/rules_detekt/detekt/wrapper/src/main/kotlin/io/buildfoundation/bazel/detekt/execute/Detekt.kt:13:13: warning: 'buildRunner(Array<String>, PrintStream, PrintStream): Executable' is deprecated. Don't build a runner yourself.
            buildRunner(args, outputPrinter, errorPrinter).execute()
            ^

What are the alternatives here?

When I clone this repo and add it as a local_repository (or a git_repository) via:

local_repository(
    name = "rules_detekt",
    path = "../../Tools/bazel_rules_detekt"
)

I am unable to build a detekt target after following readme instructions. It just hangs and times out trying to fetch the transitive closure of the 4 dependencies listed and complains its unable to fetch detekt-cli and rxjava. Ive tried adding additional repositories to the maven_install and have verified they exist in each of them - im not sure why it fails.

Is there any chance you plan on doing a release soon? I am on 6232ec8

Detekt 1.22.0 has introduced Detekt Marketplace — a way for 3rd-party rules to be distributed among users.

We need add support for Detekt Marketplace to rules_detekt so we're on par with Gradle integration.

Surfacing below error while loading both GRPC and Detekt rules:

Logs Snippet:

Error message:
ERROR: error loading package '': in external/rules_detekt/detekt/toolchains.bzl: cannot load '@rules_java//java:repositories.bzl': no such file

Pre-condition:
Used KOTLIN vanilla project for reference

Steps to reproduce:

1. Add grpc_proto rules along with detekt rules in the WORKSPACE file:

# ---------------------------------- Protobuf and gRPC rules (android) : Start ----------------------------------
http_archive(
    name = "rules_proto_grpc",
    sha256 = "28724736b7ff49a48cb4b2b8cfa373f89edfcb9e8e492a8d5ab60aa3459314c8",
    strip_prefix = "rules_proto_grpc-4.0.1",
    urls = ["https://github.com/rules-proto-grpc/rules_proto_grpc/archive/4.0.1.tar.gz"],
)

load("@rules_proto_grpc//:repositories.bzl", "rules_proto_grpc_toolchains", "rules_proto_grpc_repos")
rules_proto_grpc_toolchains()
rules_proto_grpc_repos()

load("@rules_proto//proto:repositories.bzl", "rules_proto_dependencies", "rules_proto_toolchains")
rules_proto_dependencies()
rules_proto_toolchains()

# android_proto_compile
load("@rules_proto_grpc//android:repositories.bzl", rules_proto_grpc_android_repos = "android_repos")
rules_proto_grpc_android_repos()

load("@io_grpc_grpc_java//:repositories.bzl", "IO_GRPC_GRPC_JAVA_ARTIFACTS", "IO_GRPC_GRPC_JAVA_OVERRIDE_TARGETS", "grpc_java_repositories")
maven_install(
    name="grpc_android",
    artifacts = IO_GRPC_GRPC_JAVA_ARTIFACTS,
    generate_compat_repositories = True,
    override_targets = IO_GRPC_GRPC_JAVA_OVERRIDE_TARGETS,
    repositories = [
        "https://repo.maven.apache.org/maven2/",
    ],
)
load("@grpc_android//:compat.bzl", "compat_repositories")
compat_repositories()
grpc_java_repositories()

# android_proto_library, android_grpc_library
load("@build_bazel_rules_android//android:sdk_repository.bzl", "android_sdk_repository")

# ---------------------------------- Protobuf and gRPC rules (android) : End ----------------------------------

# ---------------------------------- Detekt rules : Start ----------------------------------
rules_detekt_version="0.5.0"
rules_detekt_sha="65203efa2c7f252a9fbeba0abe651cd32c316858d3dbad550a5a34cf48bbe404"

http_archive(
    name = "rules_detekt",
    sha256 = rules_detekt_sha,
    strip_prefix = "bazel_rules_detekt-{v}".format(v = rules_detekt_version),
    url = "https://github.com/buildfoundation/bazel_rules_detekt/archive/v{v}.tar.gz".format(v = rules_detekt_version),
)

load("@rules_detekt//detekt:dependencies.bzl", "rules_detekt_dependencies")
rules_detekt_dependencies()

load("@rules_detekt//detekt:toolchains.bzl", "rules_detekt_toolchains")
rules_detekt_toolchains()
# ---------------------------------- Detekt rules : End ----------------------------------

2. Run bazel sync

Detekt has experimental support for rules that rely on type resolution.

The gradle plugin seems to have support for this. The CLI tool looks like it requires the --jvm-target and --classpath arguments to be provided. Are those paths available during the bazel compilation phase? Is it possible that the bazel rules could support these type-resolution rules?