optional action failure on cache miss

[deitch]

Can we have an option to fail on cache miss? The current behaviour is:

• cache hit: restore, exit successfully
• cache miss: do not restore, exit successfully

Much of the time, the above makes sense. But there can be workflows where you might want to fail if cache miss. For example, 2 jobs that depend on each other and use cache to move ephemeral artifacts around. We don't want them as formal artifacts, but a cache miss should cause the job to stop.

Right now, you can do it with a little convolution:

      - name: update from cache
        id: cache
        uses: actions/cache@v3
        with:
          path: foo
          key: some-key
      - name: Fail if cache miss
        uses: actions/github-script@v6
        if: steps.cache.outputs.cache-hit != 'true'
        with:
          script: core.setFailed('Cache hit failed')

That gets unwieldy, especially if it has to be done in a few jobs. The following would be much easier:

      - name: update from cache
        id: cache
        uses: actions/cache@v3
        with:
          path: foo
          key: some-key
          fail_on_miss: true      # this, or some similar key

[lvpx]

Hi there @deitch, we are planning some changes for users to have granular controls over cache. More info to follow once we have the plan finalised. Thank you for creating this issue, will keep it open for tracking currently.

[deitch]

That sounds interesting. I rather am looking forward to that.

[kotewar]

Hi @deitch ,

This looks more like a registry (npm registry/maven repository) pattern, where if the dependency is present in the registry with a required version, the build would succeed, else it would fail saying the version doesn't exist.

Is that what you are looking for?

[deitch]

Not quite @kotewar , although now that you describe it, the parallels are obvious.

In my use case, we have a long build process that creates output artifacts. These are used in multiple downstream jobs. The build is expensive, so we do it once, then cache, then pull the cache for the many downstream jobs. If they are missing, that is an issue that I want to catch and fail the job there and then, rather than waiting for some "missing artifact" error in the actual job execution.

build job ----> jobA
          ----> jobB
          ----> jobC
          ----> jobD
          ----> jobE
          ----> jobF
          ----> jobG

I looked at using workflow artifacts for this, which would work, but it is a mismatch. These are temporary outputs, useful only within the scope of the workflow. When all of the downstream jobs are done, they should go away.

[cdce8p]

This is something I've been looking for as well. I know multiple projects which have split dependency install and tests. In one workflow example the pattern is used more than 10 times. It would be awesome if a config setting could be added. That would simplify the jobs a bit.

      - name: Restore full Python ${{ matrix.python-version }} virtual environment
        id: cache-venv
        uses: actions/[email protected]
        with:
          path: venv
          key: ${{ runner.os }}-${{ steps.python.outputs.python-version }}-${{
            needs.info.outputs.python_cache_key }}
      - name: Fail job if Python cache restore failed
        if: steps.cache-venv.outputs.cache-hit != 'true'
        run: |
          echo "Failed to restore Python virtual environment from cache"
          exit 1

[kotewar]

Hey there 👋🏽

After spending a couple months and trying to accommodate the asks from multiple users. We have released two new actions that allow users to use restore and save actions individually.

However to also ensure that lot of configuration is not in place, as said by other users in https://github.com/actions/cache/issues/94 we are trying to avoid use cases that can be handled by the outputs of our current cache action. We still recommend you to continue using the cache-hit output for evaluating the same.

[cdce8p]

Thanks for the update @kotewar!

However to also ensure that lot of configuration is not in place, as said by other users in #94 we are trying to avoid use cases that can be handled by the outputs of our current cache action. We still recommend you to continue using the cache-hit output for evaluating the same.

I would disagree. Just skipped through #94 and the way I read it is that users want sensible defaults. I.e. at best just add uses: actions/cache@v3 and everything should work. That was already implemented by a lot of setup-xxx actions. For example the setup-python actions has the cache: "pip" option to do just that. https://github.com/actions/setup-python#caching-packages-dependencies

This doesn't mean though, that advanced use cases can't be made easier as well. In this particular case, users wouldn't need to look at / use exit-on-cache-miss unless they want to, since it would provide a default value which works in most cases.

[kotewar]

Hmm, I'll change the category for now to take a better look at such asks. :)

[cdce8p]

v3.2.4 was just released which adds a new option to actions/cache and actions/cache/restore: fail-on-cache-miss.

https://github.com/actions/cache/blob/main/restore/README.md#exit-workflow-on-cache-miss

[deitch]

Excellent! Thank you @cdce8p and @kotewar .

Do I need to do anything in actions to ensure it gets this? Or will all actions/cache/restore@v3 invoked after now automatically inherit this?

[kotewar]

@deitch , actions/cache/restore@v3 can use this feature using the input fail-on-cache-miss