You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cache target/ directory between runs to run sbt compile incrementally in consequtive commits in a PR.
Wait a couple days and re-try.
Expected behavior:
Because we don't have any snapshot dependencies, cache sped should be preserved.
Actual behavior:
Whenever our sbt cache gets older, probability of it running slower increases.
I have realized no console log is given during this time, meaning no actual compilation happens but something
This is the average runtime for our workflow runs over time.
Sometimes the average goes down because sbt cache is refreshed. The average goes down slower as the existing PRs that use the old cache is closed.
I suspect might be related to #408 as sbt relies on both JDK / JRE hashes and dependency hashes.
In our case, the incremental build goes from 2m to 8m slowly. And it never exceeds 8 minutes. I also measured sbt update time which is around 6 minutes. I suspect update is happening even though the cache is there.
The text was updated successfully, but these errors were encountered:
Hello @Dogacel, the problem is not reproducible. Can you please confirm it still exits and provide the logs of the builds you have noticed the problem?
Hello @Dogacel , i am closing the issue because of it is not reproducible. Feel free to create a new one or reopen this in case the problem still exists.
Description:
The cached build gets slower over time.
Task version:
v3.11.0
Platform:
Runner type:
Repro steps:
target/
directory between runs to runsbt compile
incrementally in consequtive commits in a PR.Expected behavior:
Because we don't have any snapshot dependencies, cache sped should be preserved.
Actual behavior:
Whenever our
sbt
cache gets older, probability of it running slower increases.I have realized no console log is given during this time, meaning no actual compilation happens but something
This is the average runtime for our workflow runs over time.
Sometimes the average goes down because sbt cache is refreshed. The average goes down slower as the existing PRs that use the old cache is closed.
I suspect might be related to #408 as sbt relies on both JDK / JRE hashes and dependency hashes.
In our case, the incremental build goes from
2m
to8m
slowly. And it never exceeds 8 minutes. I also measuredsbt update
time which is around 6 minutes. I suspect update is happening even though the cache is there.The text was updated successfully, but these errors were encountered: