build: dist: defer PlainSourceTarball#93047
Conversation
|
(rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
Apparently it changes some tool sources and invalidates their fingerprints, forcing us to build them several times (before and after vendoring sources). I have not dug into why vendoring actually invalidates the figreprints, but the moving the vendoring lower in the pipeline seems to avoid the issue. I could imagine that we somehow write a .cargo/config somewhere which somehow makes subsequent builds use the vendored deps but I was not able to find anything. I checked the sizes of generated archives pre and post patch and their are the same, so I hope there is not functional change. Fixes rust-lang#93033
matthiaskrgr
force-pushed
the
defer__dist_PlainSourceTarball
branch
from
6c9fe6a to
5f58a78
Compare
|
This seems okay to me, but it does seem bad that just generating the tarball has effects; it shouldn't. I can't seem to reproduce locally, either, though I haven't spent too long on various attempts -- it sounds like you were able to, though -- maybe you can comment with some steps on doing so? @bors r+ |
|
📌 Commit 5f58a78 has been approved by |
bors
added
S-waiting-on-bors
|
hmm, the commands I ran were Did a bit of braindumping at https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/what.20happened.20in.20july.202020.3F/near/268404026 but it's not much. |
|
Ah, I see. OK, well, maybe I'll spend some cycles trying to track the cause down but seems somewhat unlikely. |
|
@bors rollup=never in case it breaks something |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (1e40679): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
6 participants
Apparently it changes some tool sources and invalidates their fingerprints, forcing us to build them several times (before and after vendoring sources).
I have not dug into why vendoring actually invalidates the figreprints, but moving the vendoring lower in the pipeline seems to avoid the issue.
I could imagine that we somehow write a .cargo/config somewhere which somehow makes subsequent builds use the vendored deps but I was not able to find anything.
I checked the sizes of generated archives pre and post patch and their are the same, so I hope there is no functional change.
Fixes #93033