I am currently developing in a monorepo that has a pretty large workspace file.
Right now, I am noting that one of my testing rules, is not getting its dependency rules re-built when I update one of my tests. Here is an example of this:
load("@npm//@grafana/toolkit:index.bzl", "grafana_toolkit")
load("@build_bazel_rules_nodejs//:index.bzl", "copy_to_bin")
APPLICATION_DEPS = glob(
[
# My updated test file is included in this glob
"src/**/*",
],
) + [
"my-config-files.json"
]
RULE_DEPS = [
"@npm//@grafana/data",
"@npm//@grafana/ui",
"@npm//emotion",
"@npm//fs-extra",
]
copy_to_bin(
name = "bin_files",
srcs = APPLICATION_DEPS,
)
grafana_toolkit(
name = "test",
args = [
"plugin:test",
],
chdir = package_name(),
data = RULE_DEPS + [
":bin_files",
],
)
I then have a file called maybe something.test.ts
. I run bazel run :test
and my test might show that I failed and I see the problem and fix it. The problem is that the next time I run my test, I see from the output that it's still failing because it's running the old test instead of the new test.
The Problem
The way that I normally fix this sort of issue with stale files not updating, is by running bazel clean
. The problem is that doing bazel clean
means I clean EVERYTHING. And that makes re-running all the build steps take pretty damn long. I'm wondering if there is a way I can specify that I only clean a subset of the cache (maybe only the output of my bin_files
rule, for example). That way, rather than starting all over again, I only rebuild what I want to rebuild.
I've actually found a pretty quick and easy way to do what I was originally asking is basically to just go to the
bazel-bin
directory, and delete the output of whichever rule it is I want to re-run. So maybe in this case, I could delete thebin_files
output in my bazel-bin directory then run mybin_files
rule again.With that being said, I think @ahumsky might be right in that if you're needing to do this, it's more likely a bug with something else. In my case, I was running a build version of my rule instead of a test version of my rule. So, cleaning a subset of my cache didn't really have anything to do with my original problem.