-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[Bug] "YN0028: The lockfile would have been created by this install, which is explicitly forbidden", but yarn.lock
exists and is not modified when running yarn install
locally
#2948
Comments
Looking at the repo you linked to you haven't commited the lockfile, you're actually ignoring it https://github.com/kaliber5/ember-bdd/blob/63c5ffbda1d4884c432056d3f4f8c2ad1ee18e91/.gitignore#L16 |
Argh, dunno where that came from. Some faulty boilerplate, probably. Thanks for pointing that out. Unfortunately, this didn't help me: after un-ignoring the lockfile, checking it into the repo and removing
Here's the GitHub action failing: https://github.com/kaliber5/ember-bdd/runs/2704378275?check_suite_focus=true Running So the bug still stands, I believe. |
Running an install in your repo I see the same changes as the CI, some potential reasons:
|
I do have a
Nope, I did not ever run
I have cloned the repo to a new folder and ran But in the original project folder, Doesn't that indcate some kind of bug? Non-determinstic behavior? |
PS @merceyz Thank you for pointing me to the direction of resolving my CI issue. 🙏 |
The diff at lolmaus/ember-bdd@4d75a55#diff-51e4f558fae534656963876761c95b83b6ef5da5103c4adef6768219ed76c2deL19350 shows a workspace named |
@ylemkimon Thank you for noticing and pointing it out. But why was it removed? The actual files of the workplaces are intact at "workspaces": {
"packages": [
"apps/*",
"addons/*"
]
}, |
Hi! 👋 This issue looks stale, and doesn't feature the Note that we require Sherlock reproductions for long-lived issues (rather than standalone git repositories or similar) because we're a small team. Sherlock gives us the ability to check which bugs are still affecting the master branch at any given point, and decreases the amount of code we need to run on our own machines (thus leading to faster bug resolutions). It helps us help you! 😃 If you absolutely cannot reproduce a bug on Sherlock (for example because it's a Windows-only issue), a maintainer will have to manually add the |
Okay, my problem was that the workspace was accidentally committed into the repo as a git submodule, so no workspace files existed on the remote. That workspace existed only in my local repo. Since the workspace contained a |
I ran across the same issue. I resolve dit by deleting my cache and then reinstalling the dependencies. The yarn.lock file was then modified by the time the reinstall had completed. I believe this may have been because I checked in the cache folder initially, and then reverted it. Not sure if this then caused a discrepancy between my local environment and the checked-in repo. |
For people still experiencing this today with This issue occurred for me because my build server will always install the latest On my local machine I was building and running As soon as I updated my local yarn version to match my build machine, the lock file regenerated with some changes. Hopefully this helps anyone else coming from the googs! |
Hi guys! I am using
Even after the above tries, I still get the same error. Is there any other solution that I can try to fix the error |
Problem still exists using yarn 4.x with github action workflow |
A clean clone and yarn fixed this CI issue for me — the cacheKey in
|
## Description Re-enables (enabled by default) `yarn.lock` immutability during CI builds. Looks like [bug](yarnpkg/berry#2948) was fixed in Yarn 4 (see #665) ## References ### Jira-link: <!-- Put link to your task in Jira here --> ### Artifact URL: https://vc3prerelease.blob.core.windows.net/packages/vc-theme-b2b-vue-1.52.0-pr-963-2139-213962dc.zip https://vc3prerelease.blob.core.windows.net/packages/vc-theme-b2b-vue-1.51.0-pr-963-faa0-faa0b3e1.zip
This might be obvious to others but I recently upgraded Yarn from 4.0.1 to 4.1.0 and hit this issue.
It took me a minute but I thought to run @@ -85,7 +85,7 @@ __metadata:
magic-string: "npm:0.30.1"
ora: "npm:5.4.1"
rxjs: "npm:7.8.1"
- checksum: f1c3877fe7af6163b8119f15db4d97a0798ae38243e8d955de6da744b54717a21f9f186e197cd4286da3d2c32d605a4ae398ac273402dd62043228a75d836514
+ checksum: 10/f1c3877fe7af6163b8119f15db4d97a0798ae38243e8d955de6da744b54717a21f9f186e197cd4286da3d2c32d605a4ae398ac273402dd62043228a75d836514
languageName: node
linkType: hard So it looks like perhaps 4.1.0 has a new checksum scheme that is not backwards compatible with 4.0.1. That was not obvious in the release notes nor is it immediately apparent you have to run tldr; run |
Describe the bug
When I run
yarn install
and thengit status
I can see that there are no changes since the last commit, i. e.yarn.lock
does not get modified by runningyarn install
.Yet, when I push the commit to CI that has this GitHub Actions step:
...it fails with:
It's weird that the error message is saying "created". I was not able to google up any mentions of this specific error message. All mentions of
YN0028
say "modified", not "created".I believe this is a bug since doing
yarn install
locally does not modifyyarn.lock
, which exists and is checked into the repo.To Reproduce
I do not have a minimal reproduction, but here's a failing CI job:
https://github.com/kaliber5/ember-bdd/actions/runs/885833497
It references a commit of a public open source project on GitHub.
I was able to work around the prpblem by setting the
YARN_ENABLE_IMMUTABLE_INSTALLS
env var tofalse
. But it does not explain why Yarn is not able to use the lockfile.Environment if relevant (please complete the following information):
Additional context
The project is a Yarn Workspaces monorepo.
The text was updated successfully, but these errors were encountered: