Add source tarballs to our releases#4294
Conversation
alexcrichton
force-pushed
the
src-tarball
branch
from
a2b5dab to
c8167a1
Compare
| # Vendor all crates.io dependencies since this is supposed to be an | ||
| # offline-only-compatible tarball | ||
| mkdir /tmp/$pkgname/.cargo | ||
| cargo vendor > /tmp/$pkgname/.cargo/config.toml |
There was a problem hiding this comment.
I haven't used cargo vendor but it seems like the --versioned-dirs option would be nice.
There was a problem hiding this comment.
I think I'll leave this as the default options since that's primarily only intended if it needs to be opted-in to, but I don't think there would be any harm in passing it in.
|
|
||
| # Create the tarball from the destination | ||
| mkdir -p dist | ||
| tar -czf dist/$pkgname.tar.gz -C /tmp $pkgname |
There was a problem hiding this comment.
I'm sure other people have thought about this more than I have, but I'd be inclined to add options like --owner=root:0 --group=root:0 --sort=name and possibly --mtime=@0, to make the contents of the generated tarball independent of the runner on which it's built.
There was a problem hiding this comment.
I'm somewhat hesitant to do that because we haven't done it for any other tarballs and I'm always somewhat scared of using fancy tar options in fear that we'll eventually get a tar on some system which is too old
There was a problem hiding this comment.
Sure, that's fair. Though I just did a quick check out of curiosity, and --sort is the newest of these flags, and even the version of GNU tar in Ubuntu 16.04 had that option. Since this is only supposed to run on GitHub runners I guess I wouldn't be as concerned about whether random systems have the same options available.
jameysharp
left a comment
jameysharp
left a comment
There was a problem hiding this comment.
I still think some more options to cargo vendor and tar would be nice to have, but I'm also happy with this as-is.
This commit adds a small script to create a source tarball as part of the release process. This goes further than requested by bytecodealliance#3808 by vendoring all Rust dependencies as well to be more in line with "download the source once then build somewhere without a network". Vendoring the Rust dependencies makes the tarball pretty beefy (67M compressed, 500M uncompressed). Unfortunately most of this size comes from vendored crates such as v8, pqcrypto-kyber, winapi, capstone-sys, plotters, and web-sys. Only `winapi` in this list is actually needed for `wasmtime`-the-binary and only on Windows as well but for now this is the state of things related to `cargo vendor`. If this becomes an issue we could specifically remove the bulky contents of crates in the `vendor` directory such as `v8` since it's only used for fuzzing. Closes bytecodealliance#3808
alexcrichton
force-pushed
the
src-tarball
branch
from
6eff034 to
a690cba
Compare
|
Ok I'll go ahead and merge this then and we can follow-up with changes if necessary. |
2 participants
This commit adds a small script to create a source tarball as part of
the release process. This goes further than requested by #3808 by
vendoring all Rust dependencies as well to be more in line with
"download the source once then build somewhere without a network".
Vendoring the Rust dependencies makes the tarball pretty beefy (67M
compressed, 500M uncompressed). Unfortunately most of this size comes
from vendored crates such as v8, pqcrypto-kyber, winapi, capstone-sys,
plotters, and web-sys. Only
winapiin this list is actually needed forwasmtime-the-binary and only on Windows as well but for now this isthe state of things related to
cargo vendor. If this becomes an issuewe could specifically remove the bulky contents of crates in the
vendordirectory such asv8since it's only used for fuzzing.Closes #3808