yarn build on the root level fails on the first run, succeeds on second

[tkiapril]

Currently, yarn install --immutable fails due to postinstall script yarn build, which in turn runs yarn workspaces foreach -p run build. Somehow it was working, but due to an unknown reason not related to our codebase, it no longer runs correctly, as @planetarium/account-aws-kms fails to locate @planetarium/account, which indeed does builds before the dependent @planetarium/account-aws-kms. However, when yarn workspaces foreach -p run build is run for the second time, it does run without errors.

[Akamig]

....it's kinda silly, but after some fumbling I just gave up and end up using pnpm, which solved this somewhat recursive dependency somehow.

[tkiapril]

I wonder if nodeLinker: pnpm would work.

[Akamig]

In GH action yaml? Yep.

Check out this documentation.

https://www.swarmion.dev/docs/how-to-guides/migration-guides/yarn-to-pnpm/

[tkiapril]

No, I mean having nodeLinker: pnpm directive in .yarnrc.yml instead of having to go through the hassle of completely overhauling the packager.

[Akamig]

Oh, I didn't knew yarn is supporting pnpm as nodeLinker option! https://yarnpkg.com/configuration/yarnrc#nodeLinker

"Ghost dependency" is the keyword I was looking for, and seems worth give it a shot.

[Akamig]

FYI, I tried "yarn dedupe" and failed.

Also about the sudden failure, there was a runner vm image update on 20231030, which including diff on nodejs binary cached image. tomato tomato. https://github.com/actions/runner-images/releases/tag/ubuntu22/20231030.2

since yarn on runner vm is based on corepack, it possibly affected it's behavior.

If this failure started around 10/30, This seems the reason.

Out of context, is it normal that "Automatic Rebase" action triggered on every issue comments?

[riemannulus]

Out of context, is it normal that "Automatic Rebase" action triggered on every issue comments?

@Akamig Nah, I guess it isn't intended... IMO it was triggered by push PR events only.