greenkeeperio / greenkeeper-lockfile

:lock: Your lockfile, up to date, all the time
https://greenkeeper.io
182 stars 73 forks source link

Does not seem to work with yarn workspaces #224

Open aaronjensen opened 5 years ago

aaronjensen commented 5 years ago

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:

Switched to branch 'greenkeeper/default/serverless-1.37.0'
package.json: No dependency changed
functions/package.json: Without either an "npm-shrinkwrap.json", "package-lock.json" or "yarn.lock" file present there is no need to run this script

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:

Only uploading on one build job

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!

jbinto commented 5 years ago

Same problem here.

Only uploading on one build [...] Is that a bad thing? Did it upload my lockfile or not?

I interpret Only uploading on one build job when running greenkeeper-lockfile-upload as trying to make sure it doesn't commit/push multiple times, in the case the job is re-run on CI or if there are new commits. The intention appears to be prevent double pushes, but this message is misleading when zero pushes have happened.

For CircleCI it comes down to this line: https://github.com/greenkeeperio/greenkeeper-lockfile/blob/4e970b4f6e249f13e9b9f1ec9dee05860fd0cd99/ci-services/circleci.js#L23

  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 chore\(package\): update lockfiles.

This is because greenkeeper-lockfile-upload did not commit anything. It did not commit anything, as @aaronjensen points out, because it bailed when it saw no yarn.lock in the subpackages.

package.json: No dependency changed
packages/example-client/package.json: Without either an "npm-shrinkwrap.json", "package-lock.json" or "yarn.lock" file present there is no need to run this script
packages/example-server/package.json: Without either an "npm-shrinkwrap.json", "package-lock.json" or "yarn.lock" file present there is no need to run this script