Provide ability to restore from cache but NOT save cache #805

After doing some research, it may be worthwhile for me to look into whether the queue is even getting cache hits. If they're not (which it sound like maybe they're not), it may make sense to just disable caching altogether in the queue.

OK, I just looked at one of our jobs and DO see cache hits of the Flutter SDK, so I think this issue is still relevant.

Cache restored successfully
Cache restored from key: flutter-linux-stable-3.29.2-x64-c23637390482d4cf9598c3ce3f2be31aa7332daf
Run actions/cache@v4
  with:
    path: /home/runner/.pub-cache
    key: flutter-pub-linux-stable-3.29.2-x64-c23637390482d4cf9598c3ce3f2be31aa7332daf-bfc7f4aacbcf80ddd0adb01ff1c07d0b79b2781df10ca0f5d21e39ce6f77e63c
    enableCrossOsArchive: false
    fail-on-cache-miss: false
    lookup-only: false
    save-always: false
Cache hit for: flutter-pub-linux-stable-3.29.2-x64-c23637390482d4cf9598c3ce3f2be31aa7332daf-bfc7f4aacbcf80ddd0adb01ff1c07d0b79b2781df10ca0f5d21e39ce6f77e63c
Received 33554432 of 136985095 (24.5%), 32.0 MBs/sec
Received 136985095 of 136985095 (100.0%), 69.0 MBs/sec
Cache Size: ~131 MB (136985095 B)
/usr/bin/tar -xf /home/runner/work/_temp/5154d90d-ef9c-48e7-b5d1-663f0eb789a2/cache.tzst -P -C /home/runner/work/mobile/mobile --use-compress-program unzstd
Cache restored successfully
Cache restored from key: flutter-pub-linux-stable-3.29.2-x64-c23637390482d4cf9598c3ce3f2be31aa7332daf-bfc7f4aacbcf80ddd0adb01ff1c07d0b79b2781df10ca0f5d21e39ce6f77e63c

GitHub Action cache by design is per branch, and cache enabled for any PR branch is also by design, so that if a user push multiple times to the same PR brach it will be able to use the cache. Space used for cache usually isn't a concern because GitHub will automatically purge older cache.

If you really don't like this behavior, you can just do bundler-cache: false and manually run bundle install, then you have full control yourself with actions/cache.

GitHub Action cache by design is per branch, and cache enabled for any PR branch is also by design, so that if a user push multiple times to the same PR brach it will be able to use the cache. Space used for cache usually isn't a concern because GitHub will automatically purge older cache.

If you really don't like this behavior, you can just do bundler-cache: false and manually run bundle install, then you have full control yourself with actions/cache.

I don't think this really touches on the point I'm making. I understand how the caching works, and I understand why it's beneficial. The problem is that merge-queue branches are single-use, and therefore it does not make sense to persist to the cache from them.

Space used for cache usually isn't a concern because GitHub will automatically purge older cache.

This is exactly the problem--if your cache is being bloated by merge-queue runs (ours is), cached items will be purged sooner than necessary. There are times where our cache bloats to 20GB (I've seen it as high as 60!) due to the throughput on our repo. In other cases where we have control over the caching strategy (i.e. where we're caching ourselves via actions/cache/save, we do not save cache in the queue, and this has been helpful in alleviating cache bloat).

In that case the best way to do it would be detect if a run is from merge queue, which can be don by check github.event_name, and then disable writing cache. PR would be welcome.

Also for now maybe you can do something like this as a workaround:

    - uses: ruby/setup-ruby@v1
      with:
        ruby-version: '3.4'
        bundler-cache: ${{ github.event_name != 'merge_group' }}
    - if: github.event_name == 'merge_group'
      run: bundle install

I wonder if it might make sense to file a similar issue to https://github.com/actions/toolkit/, i.e. if it never makes sense to save cache for merge_group, then maybe cache.saveCache() should noop in that case.