I'm seeing the same bad behavior.
As a workaround, I added a string comparison to my workflows:

      if: ${{ (!steps.cache-restore.outputs.cache-hit || steps.cache-restore.outputs.cache-hit == 'false') }}

This is cause by #1404, which was a major breaking change.
It is not clear why the change was necessary.

It also breaks https://github.com/AnimMouse/setup-rclone, see AnimMouse/setup-rclone#10

It's sad that it's 2024, and GitHub Actions still can't make their type system right!
true and false are booleans, not strings!

This should be fixed in https://github.com/actions/cache/releases/tag/v4.1.1, the v4 tag will be updated soon.

@joshmgross,
Thank you.

Maintainers, you're doing quite well job. I'm not being sarcastic. Pray for your mental safety.

The behavior change was intentional to make it consistent with the documentation. The outputs of GitHub Actions have never supported booleans. You shoud check against a string 'true'.

It was an regression that the output is not set in v4. Yes, the behavior change was intentional to fixing the regression. In v3, cache-hit == 'false' worked! But leaving the regression too long allowed people depending on the undocumented (or proposed in #1263) behavior that the output beeing not set.

The changes are reverted right now, but the ternary output is quite difficult IMHO. Well, engineering is difficult.

@itchyny I agree that using cache-hit as-is is confusing and difficult.

Our priority is to maintain the existing behavior and avoid unnecessary user friction.

The existing cache-hit output really has two purposes:

1. Indicates if a cache was restored ('' vs non-empty string)
2. Indicates if an exact cache match was found ('true' or 'false')

In the future, I'd like to break that up into two outputs so that we don't need this odd ternary string to represent all 3 cases. Ideally that would come with proper support in the Actions runner for typed outputs, but that's not currently on our roadmap.

Alternatively, we adopt the changes that were reverted and properly release that as a breaking change with a v5 of this action. Major versions are not something we do often - we end up with mixed adoption across major versions and either have to maintain multiple major versions or leave users on older major versions out of important security updates or bug fixes.

I'm going to call this closed for now, but I'm open to further feedback on how we can improve cache-hit. Feel free to open an issue or discussion if you'd like to discuss that further.