-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable Corepack #480
Comments
Hi @shellscape, |
Hi @shellscape, |
Hm, I don't see anything codified in this repo that states experimental features aren't welcome. Seems that a |
A PR was already started in #482 Also, we should get clarity around the path from experimental to stable nodejs/corepack#104 |
@styfle ah I missed that, thanks for pointing it out. I'll continue discussion there. |
Hello @shellscape. I think the main reason to not enable corepack by default because some customers can use setup-node with cache enable in conjunction with pnpm/action-setup before setup-node. When corepack is enabled it will override preinstalled pnpm (from pnpm/action-setup). |
corepack will not override it to 6 unless that is what is set for |
Hello @Ethan-Arrowood. Thank you for your response. I've tried to use this snippet and it overrides pnpm version.
|
Is |
No it does not. With packageManager it works as expected. But not all users have packageManager field, that is why it can break existing behaviour some users if corepack is enabled by default with caching. |
it makes no sense to setup pnpm before node. 🤔 |
Ahh I see; then I can add a check for the |
This is necessary step in order to get caching to work. This action executes pnpm to get the path of the cache during the node set up action; if pnpm or yarn are not installed then the operation will fail. One could argue this action should start to support pnpm automatically like I believe it does with yarn |
What about enabling corepack explicitly using an input? - uses: actions/setup-node@v3
with:
node-version: 16
corepack-enable: true |
Hello @JanVoracek. Thank you for your suggestion. I think in this variant it won't reduce yaml file size because you also need only one line to enable it after the setup-node action. |
For me it's less about line reduction and more about consolidation. Remember: different users value different metrics, it's a folly to assume users will value the same as one's self. |
Haven't tried it yet, but I'd expect that we'd need this. See: - actions/setup-node#480
Bumps [prettier](https://github.com/prettier/prettier) from 2.8.3 to 2.8.4. - [Release notes](https://github.com/prettier/prettier/releases) - [Changelog](https://github.com/prettier/prettier/blob/main/CHANGELOG.md) - [Commits](prettier/prettier@2.8.3...2.8.4) --- updated-dependencies: - dependency-name: prettier dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
is this change released? Now for users who used a separate step to enable corepack, the github action is broken. Hence the declared goal of this change request is not met: "which is a net benefit to users in both regards". sample yaml:
The step "Setup Node.js" fails with error:
The step "Enable corepack" that follows is not executed, cause the action is already failed. |
Yeah I've noticed that as well. Initially it started happening randomly and re-triggering the CI fixed it, but now it happens consistently. The solution is to enable corepack before setup-node. I hope that one day setup-node will officially support corepack and such hacks won't be necessary anymore. |
like we had - name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: "18"
cache: 'yarn' after removing it solved the problem 🤷♂️ |
CI was failing, probably because of a change in the setup-node action: https://github.com/gilbsgilbs/babel-plugin-i18next-extract/actions/runs/7363053375/job/20042120587?pr=264 Enabling corepack before starting the action should fix the issue. See actions/setup-node#480 (comment)
CI was failing, probably because of a change in the setup-node action: https://github.com/gilbsgilbs/babel-plugin-i18next-extract/actions/runs/7363053375/job/20042120587?pr=264 See also actions/setup-node#480 (comment)
Explicitly putting together what others have said, this worked for me: name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Enable Corepack
run: corepack enable
- name: Use Node.js 20.x
uses: actions/setup-node@v4
with:
node-version: "20.x"
cache: 'yarn'
- name: Install dependencies
run: yarn install --immutable
- name: Run lint
run: yarn lint
- name: Run tests
run: yarn test
- name: Run build
run: yarn build |
man, how come I have to find these things in a gh issue? Is this officially documented anywhere? I'm in the process of upgrading something to yarn 4 from 1 and couldn't find anything on github actions. |
TODO: enable corepack, see actions/setup-node#480
Following [this solution](actions/setup-node#480 (comment)) to enable corepack and caching.
Description:
Related to this issue and comment #182 (comment), I'd like to see support for enabling corepack without having to have a separate
run
step to do so.Justification:
This would reduce overall runtime of actions, as no separate steps are required to enable corepack nor to install package managers, which is a net benefit to users in both regards.
Are you willing to submit a PR?
Surely
The text was updated successfully, but these errors were encountered: