-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generate XZ-compressed tarballs #41600
Conversation
instead of combining the component and target into a URL.
The same unavailable target value is used in two different places. Abstracting it makes it easier to update it and recognise its purpose.
(rust_highfive has picked a reviewer for you, use r? to override) |
I tried to add the required packages to the CI infrastructure, but I am not very confident that everything is in place. I trust the CI itself to warn about such issues. |
You can use ALLOW_PR to get rapid feedback; doing it on one of the builders (preferably x86_64-linux-gnu) doesn't jam the queue so much. Make sure you add some sort of WIP tag. |
Who should review this? Not, I think, me. |
r? @alexcrichton -- feel free to pick someone else, I figured you'd know the right person tho |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks excellent to me, thakns @ranma42!
Right now if this gets past bors then we unfortunately don't have many guarantees. It should exercise all xz-producing code but doesn't exercise the manifest generator, that'll happen when the next nightly is built.
You can also run everything locally (at least container-wise) with ./src/ci/docker/run.sh arm-android
(etc)
}; | ||
let xz_filename = filename.replace(".tar.gz", ".tar.xz"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't currently validate that the xz file actually exists, could that be done as an extra sanity check?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
self.digests
should only contain digests for existing files. Do you expect the file to be deleted between the digest computation and the construction of the manifest?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh good point yeah, but that means that the url could be specified and the digest could be none, right? Could we statically prevent a situation such as that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
xz_url: xz_digest.as_ref().map(|_| self.url(&xz_filename))
makes sure that the url is only specified if the digest is Some
thing (and that its contents are based on the filename, not on the digest value).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gah sorry, yes of course!
@@ -11,6 +11,7 @@ RUN apt-get update && apt-get install -y --no-install-recommends \ | |||
cmake \ | |||
sudo \ | |||
gdb \ | |||
p7zip-full \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A bunch of containers don't actually produce tarballs, only the dist-*
ones do I believe. Could this package be left out of all the containers (like this one) not producing tarballs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uhm... Actually I might have removed one too many: does the cross
image also produce tarballs? Even if it is not dist-*
, it is flagged DEPLOY=1
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops yes sorry DEPLOY=1
is the marker to look for.
cc @brson |
Out of curiosity: why are you using p7zip rather than xz-utils (which is already being installed)? |
@mattico 7z is available on AppVeyor (where it is somewhat harder to install software). See rust-lang/rust-installer#57 (comment) |
Ok everything looks great to me @ranma42! Want to squash and remove '[WIP]' and r+? |
Squashed and renamed :) |
@bors: r+ |
📌 Commit 36b9ab7 has been approved by |
⌛ Testing commit 36b9ab7 with merge 5616298... |
💔 Test failed - status-travis |
Uh, of course |
@bors: r+ |
📌 Commit bf4082a has been approved by |
⌛ Testing commit 6bf71f0 with merge d5948bd... |
💔 Test failed - status-travis |
Looks legitimate:
(https://travis-ci.org/rust-lang/rust/jobs/228215768) @bors r- |
MacOSX does not ship `7z` nor `xz`. Let's use `xz`, just like on the other *nix systems.
I must have messed up when squashing the update of the rust-installer submodule, sorry. It should be fixed by my latest push. |
@bors: r+ |
📌 Commit 5e522d7 has been approved by |
Generate XZ-compressed tarballs Integrate the new `rust-installer` and extend manifests with keys for xz-compressed tarballs. One of the steps required for rust-lang#21724
⌛ Testing commit 5e522d7 with merge 234472d... |
Think this caused a rollup failure in #41725 on the osx xcode 7 builders
Can't decipher why from the logs, but both of the osx xcode 7 builders failed, so I suspect it'll fail here as well. |
@aidanhs oddly enough all builders have gotten past the xz installation stage here ... |
@bors: retry |
Wrap the installation on macOS with `travis_retry`.
I added |
@bors: r+ Yeah I also found that log... interestingly ordered |
📌 Commit 98dd82c has been approved by |
Generate XZ-compressed tarballs Integrate the new `rust-installer` and extend manifests with keys for xz-compressed tarballs. One of the steps required for rust-lang#21724
As of rust-lang/rust#41600 we now need `xz` to build Rust from HEAD.
Integrate the new
rust-installer
and extend manifests with keys for xz-compressed tarballs.One of the steps required for #21724