This message was deleted.
# dependency-management
s
This message was deleted.
c
We use the BuildCache, even for the Android UI Tests, and we decided it's good enough
v
I have own scripts. It is huge difference if you run all test (60+ min) and only changed files (few seconds)
r
@Vojtech Hrdina you have your own scripts to do what?
@CristianGM are you talking about gradle's remote build cache?
c
yes
🙌 1
v
@Ryan Fioravanti To find modified files and run tests for them instead of running all tests. It is almost same as AffectedModuleDetector. I didn’t know that plugin like this exists…
r
and @Vojtech Hrdina are you using the gradle build cache in addition? We already use remote build cache so I'm specifically wondering if I'll expect to see value in using both cache and this plugin together
v
@Ryan Fioravanti No. I experimented with remote cache but I always use clean builds
c
BuildCache is confiable. Detecting affected tests requires instrumenting and it's a complex thing that could be error prone. Even if done right, the benefits are bigger the less you modularize, and to our use case has a disadvantage: I want to have the full report to compare coverage between commits, if I don't run some tests I can't recalculate how it changed.
So, that's why I didn't invest on that. I understand there may be scenarios where it's worth.