Berry: [Bug] YN0018 in github actions when using TypeScript

[eps1lon]

Describe the bug

yarn install fails with on GitHub actions but not locally with YN0018

• yarn cache clean --all did not help
• updating yarn to latest did not help
• updating yarn to sources did not help

Also tried:

/D/p/m/typescript-to-proptypes (master|✔) $ yarn -v
2.0.0-rc.31.git.20200327.c2902096
~/D/p/m/typescript-to-proptypes (master|✔) $ yarn cache clean --all
➤ YN0000: Done in 0.07s
~/D/p/m/typescript-to-proptypes (master|✔) $ set -x YARN_CHECKSUM_BEHAVIOR update
~/D/p/m/typescript-to-proptypes (master|✔) $ yarn

which did not change anything. The install did take quite a while though. It seemed to be frozen after it downloaded everything.

To Reproduce

1. Clone https://github.com/merceyz/typescript-to-proptypes
2. yarn install
3. works fine
4. same commit fails in github actions: https://github.com/merceyz/typescript-to-proptypes/runs/547813870

Screenshots

https://github.com/merceyz/typescript-to-proptypes/runs/550247915#step:5:3273

Environment if relevant (please complete the following information):

• GitHub runner version 2.165.2 using ubuntu-latest

Additional context

Seems related to typescript 3.5.2

[NotMoni]

You have to install yarn berry on the CI Cd

[NotMoni]

See if that helps you

[eps1lon]

You have to install yarn berry on the CI Cd

Why would I need to do this? Yarn v1 is already installed in the github runner and berry is checked in to version control.

What would be the steps to install yarn berry in github actions?

[paul-soporan]

There's no need to install Berry on GitHub actions if it's checked in to version control. Also, the logs clearly show that Berry is the version that's used.

[vhiairrassary]

I have the exact same issue (works locally but not in Github Actions). During the installation we can see checksum mismatches such as https://github.com/merceyz/typescript-to-proptypes/runs/547813870#step:5:1204 (see following screenshot) but not sure if it is linked.

I use:

• Node: v12.16.1
• Yarn: 2.0.0-rc.31

The three errors (all linked to https://github.com/yarnpkg/berry/tree/master/packages/plugin-compat/sources/patches):

• fsevents@patch:fsevents@npm%3A1.2.12#builtin::version=1.2.12&hash=77dfe6: The remote archive doesn't match the expected checksum
• resolve@patch:resolve@npm%3A1.15.1#builtin::version=1.15.1&hash=8fccd0: The remote archive doesn't match the expected checksum
• typescript@patch:typescript@npm%3A3.8.3#builtin::version=3.8.3&hash=270b6c: The remote archive doesn't match the expected checksum

[arcanis]

On the bright side, it seems I can reproduce those errors locally:

@eps1lon @merceyz Can you send me the archives you have in your cache that mismatch the ones in my screenshot? I'll diff them and see what might cause the difference.

[merceyz]

@arcanis Sent on discord

[arcanis]

My best guess is that this is due to this change, committed a few weeks ago:
https://github.com/yarnpkg/berry/blob/master/packages/plugin-patch/sources/patchUtils.ts#L143

It slightly changed the patch mechanism with regard to line endings to make it more consistent, but unfortunately it was already too late and I should have bumped the cache version since the old one wasn't compatible with the new one anymore.

To workaround this, try the following:

• yarn cache clean --all

At this point, running yarn install should start to fail. Then run this:

• YARN_CHECKSUM_BEHAVIOR=update yarn

It'll update the lockfile with the new cache checksums.

[eps1lon]

@arcanis I tried this two times with no luck

[missing1984]

run into the same issue. the workaround works. delete and regenerate yarn.lock also works for me @eps1lon

too early to post lol. It's still failing on CI

YN0018: │ fsevents@patch:fsevents@npm%3A2.1.2#builtin<compat/fsevents>::version=2.1.2&hash=77dfe6: The remote archive doesn't match the expected checksum
YN0018: │ resolve@patch:resolve@npm%3A1.15.1#builtin<compat/resolve>::version=1.15.1&hash=8fccd0: The remote archive doesn't match the expected checksum

My env:

• Gitlab enterprise 12.6.2
• Artifactory 6.5.18

[arcanis]

Good news! I've isolated the problem to an unstable mtime generated in the zip archives when using the patch protocol (hence why it failed for fsevents, resolve, and typescript only). The fix is #1155, it'll land in master shortly and I'll make a release not long after.

[missing1984]

awesome!

[AlexandreBonaventure]

@arcanis any workaround till this is released ?

[arcanis]

Use yarn set version from sources to install master in your project.

[eps1lon]

Fix confirmed: https://github.com/merceyz/typescript-to-proptypes/commit/d51439966c0c5607bde5c3f8eb99f94e68bd99aa

Thanks @arcanis :+1:

[niklaskorz]

Still broken for me unfortunately :(

Repository: https://gitlab.com/niklaskorz/nkchat
Failing pipeline: https://gitlab.com/niklaskorz/nkchat/-/jobs/526714686

[micaelmbagira]

Same here, it doesn't fail locally though. But it fails in gitlab or when running it in docker locally.

[niklaskorz]

It's working now after forcing git to treat *.zip as binary files in my .gitattributes:

*.zip binary

Before that, git's autocrlf would convert all occurences of CRLF line endings in the zip files to LF, eventhough they probably weren't meant as line endings in a binary file.

Edit: I explicitly marked every file as text before in gitattributes, so this issue is entirely my fault but still something to look out for!