We have a setup as described in this SO thread:
a client project has a dependency on a local package stored as a .tgz file in the same repository. Redacted package name is @company/my-library, package file path in repository is local-packages/company-my-library-2.0.0.tgz, client project sits at client/ and depends on it as "@company/my-library": "file:../local-packages/company-my-library-2.0.0.tgz"
when npm install runs in a BitBucket pipeline, it fails with the following messages. The first two messages actually appear twice. The sha512 codes are redacted for readability:
npm warn tarball tarball data for @company/my-library@file:/opt/atlassian/pipelines/agent/build/local-packages/company-my-library-2.0.0.tgz (sha512-[Same-As-Package-Lock]) seems to be corrupted. Trying again.
npm warn tar TAR_BAD_ARCHIVE: Unrecognized archive format
npm error code EINTEGRITY
npm error sha512-[Same-As-Package-Lock] integrity checksum failed when using sha512: wanted sha512-[Same-As-Package-Lock] but got sha512-[Another-Checksum]. (131 bytes)
Things we tried:
On dev machine, uninstall and reinstall local package, both on Windows and on WSL Ubuntu, also after forcing an npm cache clean --force command: the calculated checksum in package-lock remains the same.
In BitBucket pipeline, print node.js and npm versions: they're practically the same as dev machine:
| environments | node.js | npm |
|---|---|---|
| dev machine | v18.20.3 | 10.7.0 |
| pipeline | v18.20.4 | 10.7.0 |
For some reason, the checksum that npm calculates during pipeline is different from the one calculated in dev environment. There is that suspect initial message: "tarball data... seems to be corrupted", as if the file was not read correctly. But it sits in the same repository, so it should not be the case of file not downloaded correctly.
We checked here on S.O. and BitBucket community for questions related to local packages, TAR_BAD_ARCHIVE, wrong checksum, even in GitHub Actions, but with no luck.
Why does this happen? TA
I think we at least found the root cause (as usual, after writing down the issue in S.O., new things come to your mind).
In BitBucket pipeline script we listed the contents of local packages directory (ls -l /opt/atlassian/pipelines/agent/build/local-packages/): the file size shown was 131 bytes, while on dev machine the .tgz file is more than 500kb.
Then in pipeline we printed package file contents and... tadaaa:
version https://git-lfs.github.com/spec/v1
oid sha256:5cdaa2fbc2839fb5a46b7108d01b74185e1fa9623d452356d4de761a0903e03e
size 547575
That's a git LFS reference file. Our repository (locally and on bitbucket) has LFS enabled, and those binary packages are stored as LFS.
For some reason, BitBucket pipeline has not enabled Git LFS. Now on to the next quest...