bloomberg/blazingmq

dependencies.yaml: Use cache action as a whole

Closed this issue · 4 comments

Why do we call actions/cache/restore@v4 followed by actions/cache/save@v4 soon after? Why not call the whole actions/cache@v4 in one step?

Note, #744 is related to this issue.

Why do we call actions/cache/restore@v4 followed by actions/cache/save@v4 soon after? Why not call the whole actions/cache@v4 in one step?

actions/cache@v4 does both restore and save depending on whether the key exists in cache or not. If the key exists, the restore operation is executed. If the key is not present in cache, the save operation is executed (only if the folder to be cached exists in the filesystem, otherwise the operation is skipped).

Using actions/cache/restore@v4 and actions/cache/save@v4 is just a more explicit approach for caching.

Using actions/cache/restore@v4 and actions/cache/save@v4 is just a more explicit approach for caching.

Yes, this is exactly why.

If you open yaml scenario and look randomly at the cache action save or restore, you already know everything you need without extra context. Moreover, when you read this, you get an extra context about the following or previous actions. If you want to save a cache, you will build and prepare something before. If you load a cache, you can expect to use it after.

On the other hand, if you see the general word cache you don't know anything without checking its usage context, and it is more mentally exhausting. This is small, but from these small moments the overall complexity of the codebase increases.

Rational checks out