-
Notifications
You must be signed in to change notification settings - Fork 170
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
feat: bump Known Good Release when downloading new version #364
Conversation
@@ -193,6 +196,29 @@ export async function installVersion(installTarget: string, locator: Locator, {s | |||
} | |||
} | |||
|
|||
if (process.env.COREPACK_DEFAULT_TO_LATEST !== `0`) { | |||
let lastKnownGoodFile: FileHandle; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Not a fan of working with file handles; it makes the code harder to follow for something that's relatively trivial perf-wise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We were reading and parsing the same JSON twice, so at least that should improve the perf ever so slightly. But I think it's the only way to avoid race conditions in case other processes are touching the same file.
The lockfile generation tool `yarn` fails when used in the `phylum-ci` Docker image as a non-root user. An example of the failure can be seen from the output of the "smoke test," which is using `scripts/docker_tests.sh` to ensure basic functionality: ``` yarn --version Internal Error: EACCES: permission denied, open '/usr/local/corepack/lastKnownGood.json' Error: EACCES: permission denied, open '/usr/local/corepack/lastKnownGood.json' ``` The same behavior happens for `pnpm`. These are the tools installed by `corepack`, which changed recently to "Bump Known Good Release when downloading new version" (nodejs/corepack#364). Part of that change was to make use of the `COREPACK_DEFAULT_TO_LATEST` environment variable to *not* update the last known good version, but setting that to `0` does not appear to prevent *all* writes (or creating a file handle with write permission) to the `lastKnownGood.json` file. This fix simply modifies the file permissions for `lastKnownGood.json` so that non-root users can read and write to it. This approach may seem specific to a file that may change name or location in the future, but the alternative method of adding `${COREPACK_HOME}` to the list of directories that get updated with a `chmod -vR 777` was deemed to be too blunt and therefore less desirable.
The lockfile generation tool `yarn` fails when used in the `phylum-ci` Docker image as a non-root user. An example of the failure can be seen from the output of the "smoke test," which is using `scripts/docker_tests.sh` to ensure basic functionality: ``` yarn --version Internal Error: EACCES: permission denied, open '/usr/local/corepack/lastKnownGood.json' Error: EACCES: permission denied, open '/usr/local/corepack/lastKnownGood.json' ``` The same behavior happens for `pnpm`. These are the tools installed by `corepack`, which changed recently to "Bump Known Good Release when downloading new version" (nodejs/corepack#364). Part of that change was to make use of the `COREPACK_DEFAULT_TO_LATEST` environment variable to *not* update the last known good version, but setting that to `0` does not appear to prevent *all* writes (or creating a file handle with write permission) to the `lastKnownGood.json` file. This fix simply modifies the file permissions for `lastKnownGood.json` so that non-root users can read and write to it. This approach may seem specific to a file that may change name or location in the future, but the alternative method of adding `${COREPACK_HOME}` to the list of directories that get updated with a `chmod -vR 777` was deemed to be too blunt and therefore less desirable. --------- Co-authored-by: Kyle Willmon <[email protected]>
When Corepack downloads a new version, it checks if it corresponds to same major as the global cached one, and if it does, it uses the more recent one the next time the global version is used. That should give users a more smoother experience as they won't need to call
corepack install -g
as often – with this PR, it should be needed only when wanting to use a different major, assuming you work on projects that keep their"packageManager"
field up-to-date.