Skip to content
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

Merged
merged 6 commits into from
Feb 22, 2022

Conversation

mina86
Copy link
Contributor

@mina86 mina86 commented Feb 8, 2022

No description provided.

Copy link
Contributor

@matklad matklad left a 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)

@@ -1,8 +1,12 @@
env:
RUST_BACKTRACE: short
RUSTFLAGS: -D warnings -W unreachable-pub -W rust-2021-compatibility
Copy link
Contributor

@matklad matklad Feb 8, 2022

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.

Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@matklad
Copy link
Contributor

matklad commented Feb 8, 2022

Hey, it does work, 🎉

Compiling proc-macro-crate v0.1.5
--
  | error: unreachable `pub` field
  | --> tools/rpctypegen/macro/src/lib.rs:16:5
  | \|
  | 16 \|     pub schema: BTreeMap<String, ErrorType>,
  | \|     ---^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

https://buildkite.com/nearprotocol/nearcore/builds/13184#6ce34762-ad12-491a-b85e-4d5b151d406f/94-443

@mina86 mina86 marked this pull request as ready for review February 8, 2022 14:17
@near-bulldozer near-bulldozer bot merged commit 8cd38f5 into near:master Feb 22, 2022
@mina86 mina86 deleted the env branch March 2, 2022 23:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants