Fixed method for checking cache-hit

[schneider10]

When checking cache-hit, this action will return an empty string on no hit, not 'false'. Therefore the correct method is to now check for !=true (see: https://github.com/actions/cache#Skipping-steps-based-on-cache-hit)

Why:

This doc is out of date or sharing incorrect info for the latest cache action.

What's being changed:

The documented method to check for a cache hit.

Check off the following:

• [x] I have reviewed my changes in staging (look for "Automatically generated comment" and click Modified to view your latest changes).
• [x] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

• [ ] This pull request impacts the contribution experience
  • [ ] I have added the 'writer impact' label
  • [ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

[welcome[bot]]

Thanks for opening this pull request! A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.

[github-actions[bot]]

Automatically generated comment ℹ️

This comment is automatically generated and will be overwritten every time changes are committed to this branch.

The table contains an overview of files in the content directory that have been changed in this pull request. It's provided to make it easy to review your changes on the staging site. Please note that changes to the data directory will not show up in this table.

---

Content directory changes

You may find it useful to copy this table into the pull request summary. There you can edit it to share links to important articles or changes and to give a high-level overview of how the changes in your pull request support the overall goals of the pull request.

Source	Preview	Production	What Changed
actions/using-workflows/caching-dependencies-to-speed-up-workflows.md	fpt ghec ghes@ 3.6 3.5	fpt ghec ghes@ 3.6 3.5

---

fpt: Free, Pro, Team ghec: GitHub Enterprise Cloud ghes: GitHub Enterprise Server ghae: GitHub AE

[janiceilene]

@schneider10 Thanks so much for opening a PR! I'll get this triaged for review ⚡

[github-actions[bot]]

Thanks for opening a pull request! We've triaged this issue for technical review by a subject matter expert :eyes:

[lucascosti]

When checking cache-hit, this action will return an empty string on no hit, not 'false'.

👋 @N-Usha @bishal-pdMSFT Could you have a look at this and see if it might be a bug in the cache action? I've replicated the behavior here (with debug logging on).

In the action's code, it does look like a false value should be set for the output for a cache miss, and there does seem to be a test for this in the repo too.

[N-Usha]

Yes @lucascosti , the doc may need an update.. Including @aparna-ravindra who's verifying this from the code.

[aparna-ravindra]

In the action's code, it does look like a false value should be set for the output for a cache miss, and there does seem to be a test for this in the repo too.

@lucascosti, Unfortunately, the method in the test case you referred is not used in the action. The value for cache-hit is set to false in three cases:

1. Cache feature is not available (here).
2. If there was a cache restored - but on one of the restore-keys and not the primary key (here)
3. Any unhandled exception (here).

However, if no cache was restored (either on the primary key or the restore-keys), then the cache-hit output value is not set. Therefore, the right way to test is to check for cache-hit != true as we see in the examples here

[lucascosti]

@lucascosti, Unfortunately, the method in the test case you referred is not used in the action. The value for cache-hit is set to false in three cases:

Thanks a lot for confirming this, @aparna-ravindra! 🙇‍♂️ My next question (possibly more for @N-Usha): is this behavior deliberate? If cache-hit is a boolean for determining if a cache hit on key happens, shouldn't it return false for any situation where there wasn't a cache hit on key?

I guess I'm trying to think of a case where returning a null value for when no cache was restored would be the desired/expected outcome. 🙃 I would have expected a null value returned for situations 1. (Cache feature is not available) and 3. (Unhandled exception) in the post above.

If it is deliberate, I'll take care of getting the docs updated (e.g. this section will also need updating) 👍

[aparna-ravindra]

Given that there are two possible values (null and false) that indicate cache-miss, checking for cache-hit != true will address both cases. Hence, I vote for updating the doc and thereby keeping it consistent with the example in the actions/cache public repository as well.

[github-actions[bot]]

This is a gentle bump for the docs team that this PR is waiting for technical review.

[jsoref]

Sounds like this is related to https://github.com/actions/cache/pull/717 / https://github.com/actions/cache/issues/661#issuecomment-1019511446

[github-actions[bot]]

This is a gentle bump for the docs team that this PR is waiting for technical review.

[aparna-ravindra]

@lucascosti Please feel free to ping if you need any more inputs from me.

[aparna-ravindra]

@lucascosti , we have a couple more requests (like this one) asking for doc update. How do we go about triaging this PR?

[lucascosti]

@lucascosti , we have a couple more requests (like this one) asking for doc update. How do we go about triaging this PR?

Sorry, @aparna-ravindra; I've been on some extended leave and this one slipped through the cracks. I'll get this reviewed and merged. 👍

[github-actions[bot]]

Thanks very much for contributing! Your pull request has been merged 🎉 You should see your changes appear on the site in approximately 24 hours. If you're looking for your next contribution, check out our help wanted issues :zap:

[bchen1029]

@lucascosti this PR help setting cache hit on false when no hit. I think this is ideal solution as you do. Could you help check this PR https://github.com/actions/cache/pull/876 if you're free? really appreciate!

[lucascosti]

Sorry, @bchen1029; the Actions engineering team will have to review those changes; I'm a docs writer and defer to them for any functionality changes.