Closed Danielku15 closed 9 months ago
doesn't that already exist? 👀
https://github.com/actions/cache/blob/main/restore/action.yml#L32
if: ${{ steps.cache-restore.outputs.cache-matched-key != '' }}
Stupid me 🤦♂️. I have completely missed this because it is not available and documented on the main cache action but only on the restore "sub-action":
Closing this issue.
I understand that currently it is by design that
cache-hit
is not set to true ifrestore-keys
is used even though I don't fully understand yet why this is the design decision.There are various use-cases where as a workflow author I don't care if an exact key or a partial key was matched. As long the cache was restored I can assume that I can skip certain steps thanks to that.
Caches cannot be updated and it is required that we have unique keys. And that breaks quite some workflows where you want to know caches were restored unless you build something custom.
Therefore I propose an alternative output for the scenario where caches were restored using partial keys via
restore-keys
. My first idea was to have one additional output with following semantics:restored-key
(string) - Set to the exact key used when restoring the cache regardless of whetherrestore-keys
orkey
was used on the restore action. Empty if no cache was found and restored.Use cases:
if: ${{ steps.cache-restore.outputs.restored-key != '' }}
Setting
restored-key
for both scenarios (key
andrestore-keys
) allows authors a less error prone experience in switching between the two restore modes. If the key ever changes and is required for further steps, no changes have to be made to the workflow beside the cache step.If this proposal is accepted I would be willing to contribute this feature.
Related issues/discussions: