[Bug?]: YARN_CHECKSUM_BEHAVIOR=reset does not work

[goloveychuk]

Self-service

• [X] I'd be willing to implement a fix

Describe the bug

Docs declaring three available options for YARN_CHECKSUM_BEHAVIOR, one of them is reset. But it does not work, I also don't see an implementation. https://github.dev/yarnpkg/berry/blob/4a097fa80c0fc42e3d5eb51c597bf7304e981111/packages/yarnpkg-core/sources/Cache.ts#L208

I think this option is important for two cases.

1. local devex, when developer change a zip archive (which vscode extension allows), eventually dev would want to clear changes and replace it with remote archive.
2. much more important: ci usage. I'm not sure how, but I've got a failed build because of checksum mismatch on CI. Cache path is shared, maybe it's because of yarn version change or compression level or smth else. From my perspective, for Ci usage, all update, ignore and throw options are not sophisticated. Throw is bad for CI usage, no way to fix it, first two options does not replace "broken" file. I think CI should use yarn.lock as source of truth, and replace "broken" archives.

Also, I think, checksumBehavior in yarnrc should be 'reset' as default if IsCi===true

I can create a PR, if solutions is ok.

To reproduce

1. yarn install with pnp enabled
2. change zip archive
3. YARN_CHECKSUM_BEHAVIOR=reset yarn should remove broken files and replace them with from remote.

Environment

System:
    OS: macOS 12.2
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
  Binaries:
    Node: 14.17.6 - /private/var/folders/_c/5f907xz5253bhss7ytr8m8zh0000gn/T/xfs-0d97552e/node
    Yarn: 4.0.0-rc.14.git.20220721.hash-4a097fa - /private/var/folders/_c/5f907xz5253bhss7ytr8m8zh0000gn/T/xfs-0d97552e/yarn
    npm: 6.14.15 - /var/folders/_c/5f907xz5253bhss7ytr8m8zh0000gn/T/fnm_multishells/57279_1658844880383/bin/npm

Additional context

No response

[yarnbot]

Hi! 👋

This issue looks stale, and doesn't feature the reproducible label - which implies that you didn't provide a working reproduction using Sherlock. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it or you edit your first post to include a formal reproduction (you can use the playground for that).

Note that we require Sherlock reproductions for long-lived issues (rather than standalone git repositories or similar) because we're a small team. Sherlock gives us the ability to check which bugs are still affecting the master branch at any given point, and decreases the amount of code we need to run on our own machines (thus leading to faster bug resolutions). It helps us help you! 😃

If you absolutely cannot reproduce a bug on Sherlock (for example because it's a Windows-only issue), a maintainer will have to manually add the upholded label. Thanks for helping us triaging our repository! 🌟