We hit a case within Salesforce where an internal lib had a dependency on mockito for testing, and they forgot to scope it as a test dep in their pom.xml. When this library was added to the dependency graph in Bazel, this mistake ended up causing multiple services to quietly have mockito in them. Luckily, something about including it (likely because it also includes objenesis) caused a strange error in a few tests, so we noticed it.
However, the error appeared during a major dep upgrade, and the failures were hard to diagnose, so we almost thought they were just flaky. It also tooks hours of running tests before we hit it. Not to complain, but it kind of ruined my evening. It would have been nicer if the springboot rule blew up immediately when this bad dep was added. The big shots are calling that 'shift-left' these days.
What we want:
springboot rule will blow up the build if something obviously incorrect is added to a springboot service
default this feature to be enabled, with the default set being common test deps (junit, mockito)
I am hand waving here about the actual format of the banned list. Do we match against Bazel labels, or the materialized jar file names? Something to figure out.
If a use case that requires junit/mockito/etc to be included in a spring boot jar (e.g. integration test appliance), the user would have to override deps_banned_regex = []
❓ Why not use Bazel's testonly feature for this (at least, for the mockito problem)? We have had to back off of that. We may still implement that in our repo, but just haven't had the time to figure it out. An early attempt at testonly enforcement broke for us due to some use cases with an internal integration testing framework, so we removed it.
plaird
commented
8 months ago
We hit a case within Salesforce where an internal lib had a dependency on mockito for testing, and they forgot to scope it as a test dep in their pom.xml. When this library was added to the dependency graph in Bazel, this mistake ended up causing multiple services to quietly have mockito in them. Luckily, something about including it (likely because it also includes objenesis) caused a strange error in a few tests, so we noticed it.
However, the error appeared during a major dep upgrade, and the failures were hard to diagnose, so we almost thought they were just flaky. It also tooks hours of running tests before we hit it. Not to complain, but it kind of ruined my evening. It would have been nicer if the springboot rule blew up immediately when this bad dep was added. The big shots are calling that 'shift-left' these days.
What we want:
I am hand waving here about the actual format of the banned list. Do we match against Bazel labels, or the materialized jar file names? Something to figure out.
If a use case that requires junit/mockito/etc to be included in a spring boot jar (e.g. integration test appliance), the user would have to override deps_banned_regex = []
❓ Why not use Bazel's testonly feature for this (at least, for the mockito problem)? We have had to back off of that. We may still implement that in our repo, but just haven't had the time to figure it out. An early attempt at testonly enforcement broke for us due to some use cases with an internal integration testing framework, so we removed it.