yarn.lock bad hash for github branch

[alansouzati]

I have a dependency from a Github branch which in my local the hash is different from a docker images (for example)

Do you want to request a feature or report a bug?
Report a bug

What is the current behavior?

Inside yarn.lock the hash for the branch is always ca2e901db63a8976d4eeb782aa11413ba43890f2 which presents problems when I'm trying to run a docker image.

error https://github.com/grommet/grommet/tarball/stable: Bad hash. Expected "ca2e901db63a8976d4eeb782aa11413ba43890f2" but got "1bf8d11e0b3066c1354f24fe073044cddc7c15b3" 

What is the expected behavior?

No bad bash

Please mention your node.js, yarn and operating system version.

Node 6.9.1
Yarn 0.17.3

[markstos]

Why do your Git branch hashes differ locally vs Docker?

One reason could be that you are automating merging one branch into another, which could produce different hashes.

If that's the issue, you can create a stable hash by creating a merged branch on Github, and then pulling that branch down locally and in your Docker so that the SHA is the same in the both cases.

If I've guessed the issue correctly, I would say that's a flaw in your DevOps and not with yarn. Using an unstable SHA when you could be using a stable SHA will continue to cause you other headaches. I've been down the same road before.

[alansouzati]

Why do your Git branch hashes differ locally vs Docker?

This is a million dollar question 😄 The one in docker is the right one. If I delete my yarn.lock and create it again it remains the same always. I ran yarn cache clean and it finally grabbed the latest one. But I'm afraid this problem will eventually come again.

My package.json is like this:

{
  "dependencies": {
     "grommet": "https://github.com/grommet/grommet/tarball/stable"
  }
}

I'm not explicitly using the SHA in the dependency, so I'm not sure what you mean by merged branch, I'm sorry.

[markstos]

OK, maybe you want both locations to point to the HEAD of a constantly changing branch. If that's the end goal, I don't have answer for you. If it's acceptable to point a specific commit in your case, I think that would resolve the issue for you and make sure your Docker and local workspace are using the exact same code. Then when you want to start using a newer version, you can change the SHA you point too, and again both your local and Docker workspace will be in sync, both pointing to the same newer version.

I recommend that pattern for the consistency it produces, regardless of whether yarn could be behave better when pointing to a frequently changing Git repo.

[alansouzati]

It is for sure the same code. I can point to HEAD which is my intended behavior.

I cannot validate that this will work because the yarn.lock results in the same hash as I have now. Whenever there is a update in my "stable" branch I can make sure that that cache will not break again.

I'm closing the issue for now. I can reopen if the problem persists.

Thanks for your help.

[alansouzati]

Now this is what I'm getting:

https://github.com/grommet/grommet/tarball/stable: Bad hash. Expected "HEAD" but got "1bf8d11e0b3066c1354f24fe073044cddc7c15b3" 

[alansouzati]

This is a CI build in travis with this issue https://travis-ci.org/grommet/grommet-docs/builds/178451849

If I run yarn cache clean, update my yarn lock file. then it works.

But I don't want to keep updating my yarn lock file for github branches.

[alansouzati]

any updates on this issue? I'm still facing this problem eventually.

[alansouzati]

We can always reproduce the issue when the following situation happens:

1. Yarn.lock gets outdated when updates are pushed to the stable branch
2. You are on a fresh machine where there is nothing in the yarn cache. Or you run yarn cache clean
3. You run yarn install

Then you get the Bad Hash problem.

[brennongs]

Also seeing this issue with different dependencies. Just pulled from github and can't install due to bad hash error. Any updates on this?

===UPDATE===
I executed a bad replace all while programming. Regenerating yarn.lock and committing to master resolved my issue.

[deregtd]

Ditto on this issue. We're having to do incredibly unnatural things in our package.json and build scripts to properly clean things to work around this. :(

[olingern]

Closing this. If this is is still an issue on 1.21.1, please comment and I'll reopen.