You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for fixing the static build in #123! I just tried to see if I could reproduce it, so I can safely download the binary from GitHub and confirm the shasum for my downstream use case, instead of having to build it from source. However, I don’t get exactly the same binary as the one on the release page.
I am building commit 3b55e17, better known as v0.15.0, with nix-build nix/release.nix -A vaultenvStatic.
Diffoscope shows very few differences (this is good, it means the discrepancy is hopefully easy to resolve), all caused by a single different store path which ends up in various places in the binary.
/nix/store/y9p11057zpc5r9cqnfy2sgfgjymwv59m-vaultenv-static-x86_64-unknown-linux-musl-0.15.0 is what’s in the published release.
/nix/store/kkb4w0i0qvhj60kdnxpasldq79glnmvg-vaultenv-static-x86_64-unknown-linux-musl-0.15.0 is what I get in my local build.
In fact, the offending store path is the final output path of building vaultenvStatic in nix/release.nix. I tried git cleaning my working directory to rule out that untracked intermediate files would affect the build and I ended up with the same store path.
The published binary differs from CI
Looking at the CI logs, it looks like CI built the same kkb4w0i0… path that I got locally. From the CI logs:
installing
Installing library in /nix/store/kkb4w0i0qvhj60kdnxpasldq79glnmvg-vaultenv-static-x86_64-unknown-linux-musl-0.15.0/lib/ghc-9.0.2/x86_64-linux-ghc-9.0.2/vaultenv-real-0.15.0-BVsC6AJuNM75bSImrOaUmP
Installing executable vaultenv in /nix/store/kkb4w0i0qvhj60kdnxpasldq79glnmvg-vaultenv-static-x86_64-unknown-linux-musl-0.15.0/bin
Warning: The directory
/nix/store/kkb4w0i0qvhj60kdnxpasldq79glnmvg-vaultenv-static-x86_64-unknown-linux-musl-0.15.0/bin
is not in the system search path.
Registering library for vaultenv-real-0.15.0..
post-installation fixup
cat nix-store-locations | cachix push channable-public
compressing and pushing /nix/store/ar8mk0qq5safyzp8gnpdz4bc448hgq7k-vaultenv-0.15.0 (5.50 MiB)
compressing and pushing /nix/store/kkb4w0i0qvhj60kdnxpasldq79glnmvg-vaultenv-static-x86_64-unknown-linux-musl-0.15.0 (24.14 MiB)
All done.
Could it be that the 0.15.0 binary that is published on GitHub was produced on a developer machine with a dirty working directory? At least, one that has files in it that pass this filter, possibly Vim swap files or something?
The text was updated successfully, but these errors were encountered:
Thanks for noticing this.
This was caused by artifacts generated by the integration tests, which are incorrectly included in the build.
I have uploaded the correct binary, and I will create a PR to ignore the integration test artifacts in the build.
Thanks for fixing the static build in #123! I just tried to see if I could reproduce it, so I can safely download the binary from GitHub and confirm the shasum for my downstream use case, instead of having to build it from source. However, I don’t get exactly the same binary as the one on the release page.
Differences
I am building commit 3b55e17, better known as
v0.15.0
, withnix-build nix/release.nix -A vaultenvStatic
.Diffoscope shows very few differences (this is good, it means the discrepancy is hopefully easy to resolve), all caused by a single different store path which ends up in various places in the binary.
/nix/store/y9p11057zpc5r9cqnfy2sgfgjymwv59m-vaultenv-static-x86_64-unknown-linux-musl-0.15.0
is what’s in the published release./nix/store/kkb4w0i0qvhj60kdnxpasldq79glnmvg-vaultenv-static-x86_64-unknown-linux-musl-0.15.0
is what I get in my local build.Diffoscope output
In fact, the offending store path is the final output path of building
vaultenvStatic
innix/release.nix
. I triedgit clean
ing my working directory to rule out that untracked intermediate files would affect the build and I ended up with the same store path.The published binary differs from CI
Looking at the CI logs, it looks like CI built the same
kkb4w0i0…
path that I got locally. From the CI logs:Could it be that the 0.15.0 binary that is published on GitHub was produced on a developer machine with a dirty working directory? At least, one that has files in it that pass this filter, possibly Vim swap files or something?
The text was updated successfully, but these errors were encountered: