[Bug?]: When running with CI, Yarn Classic is used for bootstrap on workspaces.

ThatOneCalculator commented 2 years ago

Self-service

[ ] I'd be willing to implement a fix

Describe the bug

In this workflow, for some reason workspaces are using yarn classic, I have no clue as to why, given the project uses a yarn 3 lockfile.

| ➤ YN0000: ┌ Fetch step
[Lint/lint]   ❓  ::group::Fetch step
| ➤ YN0000: │ /tmp/xfs-1b69f5c1 STDOUT Packing browser-image-resizer@https://github.com/misskey-dev/browser-image-resizer.git#commit=a58834f5fe2af9f9f31ff115121aef3de6f9d416 from sources
| ➤ YN0000: │ /tmp/xfs-1b69f5c1 STDOUT Using Yarn Classic for bootstrap. Reason: "__metadata" key not found in yarn.lock, must be a Yarn classic lockfile
| ➤ YN0000: │ /tmp/xfs-1b69f5c1 STDOUT 
| ➤ YN0000: │ /tmp/xfs-1b69f5c1 STDOUT Resolving classic to a url...
| ➤ YN0000: │ /tmp/xfs-1b69f5c1 STDOUT Downloading https://github.com/yarnpkg/yarn/releases/download/v1.22.19/yarn-1.22.19.js...
^C| ➤ YN0000: │ /tmp/xfs-1b69f5c1 STDOUT Saving it into /tmp/xfs-1b69f5c1/.yarn/releases/yarn-1.22.19.cjs...
| ➤ YN0000: │ /tmp/xfs-1b69f5c1 STDOUT Updating /tmp/xfs-1b69f5c1/.yarnrc...
| ➤ YN0000: │ /tmp/xfs-1b69f5c1 STDOUT Done!
| ➤ YN0000: │ /tmp/xfs-1b69f5c1 STDOUT 
| ➤ YN0000: │ /tmp/xfs-1b69f5c1 STDOUT yarn install v1.22.19
| ➤ YN0000: │ /tmp/xfs-1b69f5c1 STDOUT [1/4] Resolving packages...
| ➤ YN0000: │ /tmp/xfs-1b69f5c1 STDOUT [2/4] Fetching packages...

To reproduce

Run in workflow

Environment

System:
    OS: Linux 5.17 Arch Linux
    CPU: (16) x64 AMD Ryzen 7 5800X 8-Core Processor
  Binaries:
    Node: 18.2.0 - /tmp/xfs-04c3d9b3/node
    Yarn: 3.2.0 - /tmp/xfs-04c3d9b3/yarn
    npm: 8.9.0 - ~/.nvm/versions/node/v18.2.0/bin/npm

Additional context

No response

yarnbot commented 2 years ago

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! 🌟

ctotheameron commented 2 years ago

@ThatOneCalculator did you ever find a resolution for this issue? I'm experiencing the same both on Netlify and Github Actions.

merceyz commented 2 years ago

for some reason workspaces are using yarn classic, I have no clue as to why, given the project uses a yarn 3 lockfile

It doesn't use Yarn 3 though, as Yarn tells you in its output, the git repo you're depending on is using Yarn classic so that is what Yarn uses to pack it.

odinho commented 10 months ago

Meh, I'm getting this too. Project definitely uses yarn 4 (via corepack).

Edit: Seems to have fixed it:

      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version-file: package.json
      - name: Set up corepack (for getting yarn)
        run: corepack enable
      - name: Get yarn cache
        uses: actions/setup-node@v4
        with:
          cache: yarn
      - run: yarn install --immutable

So running setup-node twice :shrug:

nateshmbhat commented 5 months ago

anyone found a solution for this ? i'm not using github actions but codemagic for CI/CD

ThatOneCalculator commented 5 months ago

The solution is to use Bun 😄

yarnpkg / berry