-
Notifications
You must be signed in to change notification settings - Fork 72
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
Does not seem to work with yarn workspaces #224
Comments
Same problem here.
I interpret For CircleCI it comes down to this line:
uploadBuild: env.CIRCLE_NODE_INDEX === `${env.BUILD_LEADER_ID || 0}` && isLockfileUpdate() For "re-builds" this fails on the first expression. For actual first-pass Greenkeeper PRs, it fails on the second expression. That just tests that the last commit was This is because
|
Turns out Greenkeeper doesn't work well with Yarn Workspaces, so we're turning it off. Reference: greenkeeperio/greenkeeper-lockfile#224
* chore(yarn): disable yarn workspaces Turns out Greenkeeper doesn't work well with Yarn Workspaces, so we're turning it off. Reference: greenkeeperio/greenkeeper-lockfile#224 * fix: fixed weird styled-components issue
I use yarn workspaces and greenkeeper-lockfile@2. A dependency was updated on one of the packages in the repo (the main package.json was not changed).
When running update, I see this:
The functions package.json changed, but its yarn.lock is in the root because that's how yarn workspaces work.
Then, when running upload, I saw this:
Which doesn't actually mean anything to me. Is that a bad thing? Did it upload my lockfile or not? I'm not seeing it in the branch, but I don't know if that's because my build failed (due to an intermittently failing test).
Does greenkeeper-lockfile actually work with workspaces and just have misleading output and not work when the build fails, or is it actually broken in this scenario?
Thanks!
The text was updated successfully, but these errors were encountered: