What's exactly cache-only mode?

[wzieba]

In the documentation I can see that there are two ways to use this action.

1. As wrapper around gradle command:

name: Build
on: [push]
jobs:
  check_build_test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - uses: burrunan/gradle-cache-action@v1.5
        with:
          arguments: assemble

2. As a separate step

name: Build
on: [push]
jobs:
  check_build_test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - uses: burrunan/gradle-cache-action@v1.5
      - run: ./gradlew assemble

I can see in Sample integration that the first one is preferable but in Can I use the caching part of the action only there is mentioned cache-only mode. To what "cache" does the cache-only refers to? Is it only dependency cache and not build cache ?

I've done some tests in sample repo:

1. Wrapper around gradle command does perform build cache:

55 actionable tasks: 13 executed, 42 from cache

2. Seperate step does not perform build cache

55 actionable tasks: 55 executed

[vlsi]

#1: the action launches Gradle process, and it can provide remote build cache via GitHub Actions cache. That enables efficient build cache, however, there's #21

Note: by default, when you provide arguments, then the action forcibly enables Gradle build cache. By default it is disabled, and you need to enable build cache if you want to use it.

The default behavior is:

• dependencies: file-based, incremental from "default branch"
• .m2/repository: file-based, incremental from "default branch"
• gradle-generated-jars: file-based
• build cache: remote via GitHub Actions caching API

#2: the action restores caches (at the point where it is declared in the yml) and it saves the caches at the very end of the build.

The action does try to save/restore local build cache files, however, the cache has to be enabled by the developer (e.g. add --build-cache when launching Gradle or add org.gradle.caching=true to `gradle.properties)

The default behavior is:

• dependencies: file-based, incremental from "default branch"
• .m2/repository: file-based, incremental from "default branch"
• gradle-generated-jars: file-based
• build cache: file-based

2. Seperate step does not perform build cache

Please check https://github.com/wzieba/BasicAndriodApp/runs/1166153438?check_suite_focus=true#step:8:6
Post Run burrunan/gradle-cache-action@v1.5

Save local-build-cache
  local-build-cache: creating single-layer cache image
  local-build-cache: no files to cache => won't upload empty cache

It says that there's no files in the local build cache (I guess you didn't activate it), so there's nothing to save. That's why there's no "from cache"

Note: the drawback of file-based build cache storage is that Action has to restore the cache fully.

Does that make sense?

[wzieba]

Thanks for the explanation! But there's more...

Just to make sure: when you write

remove build cache

do you mean

remote build cache

and it was just a typo? Or there's something about removing (updating?) cache?

---

It says that there's no files in the local build cache (I guess you didn't activate it), so there's nothing to save.

Yes, that's true, I didn't enable it (by mistake). So I've pushed third build with --build-cache argument.

This concluded me to the next question:

is it intended to see a difference between build cache: remote* via Github Actions caching API vs. build cache: file-based in terms of the number of cached tasks?

I can see the difference in this sample build:

1. Using action as wrapper	2. Using action as step with --build-cache
55 actionable tasks: 13 executed, 42 from cache	55 actionable tasks: 46 executed, 9 from cache

Does it mean that in the second scenario, action caches build-cache only locally, for the single build? So it'll reuse cache for one build and then disappear with the Github worker?

I can also see that the second scenario has

Restore local-build-cache
  Cache was not found

message, even after several runs, while the first scenario (action as wrapper) does not have this message (which is understandable as it'll use remote* build cache). Why local-build-cache is not restored?

Additional log from the post phase of the cache action:

local-build-cache: old contents is not found, and the current cache gradle-build-cache-Linux--gradle-6.5-cache_as_step_and_enabled_build_cache-80b01abb3040fbe5c9a7b87fe2330f4a31f5cb97
   does not start with gradle-build-cache-Linux--gradle-6.5-defaultbranch, so cache saving can't be done

[vlsi]

message, even after several runs

Well, it probably needs more explanation/better logging.

Why local-build-cache is not restored?

It is not restored because it is not stored (yet).

Let me explain: file-based build cache works similar to dependencies cache.

Let us consider dependencies cache. As you might guess, it might be huge, and GitHub has 5GiB per-repository cache limit.

That is why I do the following:

1. When action runs in PR (or in a branch), then it tries to restore dependencies cache from the relevant default branch
2. When action saves the cache, then it stores only the difference

In other words, if you run the cache action in your default branch at least once, then other branch-based (or PR-based) builds would be able to reuse that "default branch cache", so the amount of data stored "per-branch" or "per-PR" would be significantly less.

AFAIK, you have never executed the cache action in the default branch, so the action skips cache store to avoid cache pollution.

File-based build cache works in the similar way: the baseline is stored in the default branch, and other branches/PRs store just the diff.

[wzieba]

Thanks, it all makes sense! I was able to successfully use cache from the main branch (which is the default branch) after branching from it (more like a real-world case scenario). Link

I will still prefer to delegate Gradle execution to action to have Gradle Remote cache with Github Actions caching API, but it's great to understand more from this action and the ideas behind it.

As I don't have anything more to ask in this subject, I close the issue.

Thanks a lot again, I hope this issue will be helpful for some future readers too.