Conversation
Avoid Corepack download message breaking the env file (tail -n1).
Avoids conflict with YARN_CACHE_DIR that yarn may set. Cache path logic is unchanged.
- Enable Corepack so yarn 4 works (packageManager in package.json) - Remove setup-node cache: 'yarn' to avoid YARN_CACHE_DIR conflict - Add explicit yarn cache steps using ACTIONS_YARN_CACHE_PATH (same as app-test)
.github/workflows/app-test.yml
Outdated
| echo "ACTIONS_YARN_CACHE_PATH=$CACHE_DIR" >> $GITHUB_ENV | ||
|
|
||
| - name: Cache yarn dependencies | ||
| uses: actions/cache@v3 |
There was a problem hiding this comment.
https://github.com/actions/cache
The latest stable is v5. Do we need v3 for some compatibility?
There was a problem hiding this comment.
Good point. I reviewed it and I don't see a compatibility reason to keep v3 here. I tested the upgrade and the workflow still makes sense, so I'll move these cache steps to actions/cache@v5.
| run: | | ||
| CACHE_DIR=$(yarn cache dir 2>&1 | sed 's/^[[:space:]]*//' | grep -E '^/' | head -n1) | ||
| if [ -z "$CACHE_DIR" ]; then CACHE_DIR="$RUNNER_TEMP/yarn-cache"; fi | ||
| echo "ACTIONS_YARN_CACHE_PATH=$CACHE_DIR" >> $GITHUB_ENV |
There was a problem hiding this comment.
It seems some kind of cache is supported out of the box from v2, maybe this pattern was necessary only for v1? (I am not really familiar with this)
https://github.com/actions/setup-node?tab=readme-ov-file#caching-global-packages-data
https://stackoverflow.com/a/62244232/188031
There was a problem hiding this comment.
I tested that approach explicitly to simplify the workflow, but it fails for Yarn 4 projects before we even reach corepack enable.
When actions/setup-node is used with cache: "yarn", it resolves the Yarn cache inside its own step and ends up running yarn cache dir with the runner's global Yarn (1.22.22). In repositories that declare packageManager: yarn@4.x, that aborts before Corepack can be enabled.
So in this case I’m intentionally keeping setup-node without cache: "yarn", enabling Corepack first, and then resolving/caching the path manually. I also simplified that logic so the cache path resolution is now explicit for Yarn 1 and Yarn 4.
| @@ -23,17 +23,22 @@ jobs: | |||
| uses: actions/setup-node@v4 | |||
There was a problem hiding this comment.
(Not in this PR) Above this line we have apt install gettext. I've seen it's common to run apt update && ... first to make sure the package indexes are up to date.
There was a problem hiding this comment.
Yes, that makes sense as a defensive improvement. It wasn’t related to the Yarn 4 issue addressed by this PR, which is why I didn’t include it in the original change, but I agree that apt update && apt install ... would be more correct. I can include it here if you want, or leave it for a separate small cleanup PR.
…che action to v5 - keep manual Yarn cache flow so Corepack can be enabled before resolving Yarn 4 - resolve cache path explicitly for Yarn 1 and Yarn 4 instead of parsing mixed output - upgrade Yarn and npm cache steps from actions/cache@v3 to v5
2 participants
📌 References
📝 Implementation
Problem: In repos with "packageManager": "yarn@4.12.0" (e.g. dhis2-app-skeleton), the test job fails because the first use of yarn (e.g. in "Get yarn cache directory path") happens before Corepack is enabled, so the runner falls back to Yarn 1.x.
Changes in .github/workflows/app-test.yml:
Removed cache: "yarn" from the "Setup Node.js version from .nvmrc" step so yarn is not run before enabling Corepack.
Added an "Enable Corepack" step (corepack enable) right after setting up Node and before any yarn command.
Result: With Corepack enabled, repos without packageManager keep using Yarn 1.x; repos with packageManager use the specified version (e.g. Yarn 4). Dependency caching is unchanged and still done in "Get yarn cache directory path" and "Cache yarn dependencies".
📹 Screenshots/Screen capture
🔥 Testing
Run the workflow on a Yarn 1 repo (no packageManager): it should still pass.
Run the workflow on a Yarn 4 repo with packageManager (e.g. dhis2-app-skeleton): the "Unit tests" job should pass; previously it failed at "Setup Node.js version from .nvmrc" / "Get yarn cache directory path" with the Corepack error.