Restore original behavior of cache-hit output
#1467
Conversation
|
@joshmgross |
|
@joshmgross |
I can see the reasoning here but this shouldn't mean a weird behaviour should be kept just because fixing it is a breaking change. IMO having it in the release notes and making the necessary change in version number should be enough, which was already done. Having this PR merged feels like a step in the wrong direction and there should be a plan to properly handle that breaking change. |
Per https://semver.org/, a breaking change needs to be a major version bump (i.e. I agreed that we should fix this confusing behavior, but we're not ready to create a new major version of this action. |
!cache-hitisfalsewhencache-hitisfalse#1262As described in #1466, #1404 broke workflows that relied on the previous behavior of
cache-hitbeing an empty string when there was a cache miss:If
cache-hitis an empty string, this would work as expected. When cache-hit isfalse, this is a non-empty string and treated as "true".Actions outputs do not support proper boolean values, and we can't guarantee how users are interpreting this string output.
This PR reverts #1404 and updates the README to clarify all possible values of
cache-hit:This is likely confusing to users, but we should maintain the existing behavior to avoid breaking existing workflows.