fix: correctly install Yarn 1 dependencies in CI when Yarn 4 is available globally

[iskounen]

This PR updates the setup-and-install action that runs in the run-danger-yarn workflow so that it correctly installs dependencies with Yarn 1, even though the CI environment has Yarn 4 available globally.

This is done by explicitly activating the correct Yarn version via Corepack before installing, so the project's Yarn 1 is used rather than the globally installed Yarn 4.

There are also 2 other optimizations made in this PR:

1. Cache the Yarn 1 package folder so that CI doesn't have to download dependencies from scratch on every run.
2. Enable Corepack inside the action itself so it is self-contained and doesn't rely on the caller having already
   run it.

The motivation for this change was receiving the following failure in the run-danger-yarn workflow after upgrading danger to 13.0.10 in #76:

Setup Node and Install Dependencies

Prepare all required actions
Getting action download info
Download action repository 'actions/setup-node@v4' (SHA:49933ea5288caeca8642d1e84afbd3f7d6820020)
Run ./.tooling/.github/actions/setup-and-install
Node 20 is being deprecated. This workflow is running with Node 24 by default. If you need to temporarily use Node 20, you can set the ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true environment variable. For more information see: https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
Run actions/setup-node@v4
Found in cache @ /opt/hostedtoolcache/node/22.23.0/x64
(node:2415) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
Environment details
/usr/local/bin/yarn --version
/usr/local/bin/yarn --version
! Corepack is about to download https://registry.yarnpkg.com/yarn/-/yarn-1.22.22.tgz
4.10.3
/usr/local/bin/yarn config get cacheFolder
4.10.3
/usr/local/bin/yarn config get cacheFolder
/home/runner/.yarn/berry/cache
/home/runner/.yarn/berry/cache
/usr/local/bin/yarn config get enableGlobalCache
/usr/local/bin/yarn config get enableGlobalCache
true
true
yarn cache is not found
Run # Determine which directory to install in
Installing packages in: .tooling
Detected Yarn 4.10.3 (Berry)
➤ YN0000: Yarn detected that the current workflow is executed from a public pull request. For safety the hardened mode has been enabled.
➤ YN0000: It will prevent malicious lockfile manipulations, in exchange for a slower install time. You can opt-out if necessary; check our documentation for more details.

➤ YN0000: · Yarn 4.10.3
➤ YN0000: ┌ Resolution step
Resolution step
  ➤ YN0082: │ danger@npm:13.0.10: No candidates found
➤ YN0082: danger@npm:13.0.10: No candidates found
➤ YN0000: └ Completed in 2s 318ms
➤ YN0000: · Failed with errors in 2s 334ms
Error: Process completed with exit code 1.

This shows that CI is using Yarn 4 despite the project being configured for Yarn 1, and Yarn 4 refusing to resolve packages from a Yarn 1 lockfile."

🤖 Generated with Claude Code

[claude]

Code Review

Summary

This PR fixes CI dependency installation for the reusable setup-and-install composite action. It replaces setup-node's built-in Yarn cache with an explicit actions/cache@v4 step, enables Corepack, and activates the project's pinned packageManager version before installing — so the correct Yarn (1.22.22, per both package.json files) is used even when a different global Yarn (e.g. Yarn 4) is on the runner's PATH.

Issues Found

No blocking issues. The logic is sound and I verified the key assumptions against the repo:

• Both package.json and .tooling/package.json pin yarn@1.22.22, so the ^[234] Berry branch is dead for this repo today but correctly preserved for external callers of this reusable workflow.
• ~/.cache/yarn/v6 is the correct Yarn 1 Classic global cache directory on Linux, matching the pinned version.
• corepack prepare reads package.json after cd "$INSTALL_DIR", so it correctly picks up the caller-vs-tooling package manager depending on install-from-caller.

🟢 Suggestion — cache path only covers Yarn 1 (Classic). The install step deliberately supports Yarn 2/3/4 (Berry), but the cache path: ~/.cache/yarn/v6 is the Yarn 1 location. Berry uses a project-local .yarn/cache (or an enableGlobalCache-configured dir), so any caller on Yarn Berry would get no cache hit and would cache an empty/irrelevant folder. The commit message ("remove unused Berry cache path") shows this is an intentional trade-off for this repo, so this is just a flag for future Berry-based callers — not a defect.

🟢 Suggestion — redundant Corepack enable. .github/workflows/danger.yml still runs a top-level Enable Corepack step, and this action now also runs its own Enable Corepack. Harmless, but the workflow-level one is now redundant for this path and could be dropped to keep things tidy (out of scope for this diff).

Areas Reviewed

• Architecture & Design: Moving Corepack activation inside the reusable action is the right call — external callers should not have to remember to enable it. Good.
• Bugs & Edge Cases: The PKG_MANAGER extraction safely no-ops (empty string) when packageManager is absent or package.json is unreadable, falling back to whatever Yarn resolves — a reasonable default. The =~ ^yarn@ guard correctly skips activation for non-Yarn package managers.
• Security: No new untrusted input or secret handling. corepack prepare yarn@1.22.22 resolves a pinned version.
• Testing: No automated tests (CI infra); validation is inherently through CI runs.

Questions for Author

1. Does corepack prepare "yarn@1.22.22" --activate succeed without an integrity hash in the packageManager field on the runner's bundled Corepack version? Recent Corepack releases have tightened integrity expectations — worth confirming the green CI run on this PR exercised this path.
2. Is keeping the Berry (^[234]) install branch intentional purely for downstream callers, given this repo itself is pinned to Yarn 1? If so, no change needed — just confirming the intent.

Overall this looks good to merge once the CI run confirms the Corepack activation path.