-
Notifications
You must be signed in to change notification settings - Fork 618
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
buildkite: set common environment variables in env
section
#6269
Conversation
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 have been bothering me for ages, would be great if it works (I didn't find this in buildkite's docs)
.buildkite/pipeline.yml
Outdated
@@ -1,8 +1,12 @@ | |||
env: | |||
RUST_BACKTRACE: short | |||
RUSTFLAGS: -D warnings -W unreachable-pub -W rust-2021-compatibility |
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.
-W unreachable-pub
will probably break every crate of ours. I do think it's a generally good thing to have, but I am not sure if it's good enough to actually enable for our use-case. But this should be a great way to test if this actually works.
To expand on this: things about logical organization (#5516) feel like they should maybe go before mechanical organization (-W unreachable-pub
), and also -W unreachable-pub
is buggy in the compiler, and sometimes requires work-arounds.
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.
If we want to poach from rust-analyzer, than CARGO_INCREMENTAL=0
might be interesting avenue to explore to speed up CI: https://matklad.github.io/2021/09/04/fast-rust-builds.html#ci-caching. Needs substantial investigation though
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.
We do multiple cargo
invocations in ‘sanity checks’ so CARGO_INCREMENTAL=0
might be a bad idea in that particular step. For other steps it probably makes sense.
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.
My mental model of how CARGO_INCREMENTAL=0
says that it orthogonal to "several cargo invocations".
CARGO_INCREMENTAL
controls "less than compilation unit" granularity of incremental compilation: when you edit a single function, incremental compilation might allow the compiler to compile the crate with the change faster. Such fine grained incremental compilation needs a bit more CPU time, and a lot more of space on hard-drive, and setting CARGO_INCREMENTAL to zero disables that overhead.
Cross-crate instrumental compilation (your usual Makefile
model with .o
files) always works, even with CARGO_INCREMENTAL=0
.
My understanding that fine-grained incremental compilation doesn't help with making cargo build --feature foo && cargo build --feature bar
faster -- compiler doesn't share cached queries between the two invocations, it only shares queries for the same invocation, but different source code.
Hey, it does work, 🎉
https://buildkite.com/nearprotocol/nearcore/builds/13184#6ce34762-ad12-491a-b85e-4d5b151d406f/94-443 |
No description provided.