-
Notifications
You must be signed in to change notification settings - Fork 17
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
chore: optimize out retriggering 2nd stage of build + wasmopt stage #292
chore: optimize out retriggering 2nd stage of build + wasmopt stage #292
Conversation
adding dj8yfo/neardevhub-contract@cbbf0ee │ Dirty near-sdk-macros v5.7.0: the environment variable CARGO_NEAR_ABI_PATH changed
│ Compiling near-sdk-macros v5.7.0 due to Only wasm-opt computing overhead is left per each test with if the abi logic isn't being used/tested in tests, both the reasons of rebuilds can also be eliminated by doing |
8ab53be
to
5b68575
Compare
… is newer than the original wasm, which means that we have already optimized it
5b68575
to
e746699
Compare
the result of adding e746699 is measurable (numbers are from second test run to account just for rebuilds, the initial contracts build time is significantly more than the times of tests per se) update rev (normal verbosity, wasm-opt duration, wasm-opt not skipped on rerun)
update rev of cargo-near-build patch (wasm-opt stage skipped)
|
running
|
@race-of-sloths include |
@dj8yfo Thank you for your contribution! Your pull request is now a part of the Race of Sloths! Current status: waiting for finalizationThe pull request is merged, you have 24 hours to finalize your scoring. The scoring ends Thu Jan 23 12:48:20 2025
Your contribution is much appreciated with a final score of 13! @akorchyn received 25 Sloth Points for reviewing and scoring this pull request. What is the Race of SlothsRace of Sloths is a friendly competition where you can participate in challenges and compete with other open-source contributors within your normal workflow For contributors:
For maintainers:
Feel free to check our website for additional details! Bot commands
|
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.
@race-of-sloths score 13
Two nits that you might skip:)
## 🤖 New release * `cargo-near`: 0.13.2 -> 0.13.3 (✓ API compatible changes) * `cargo-near-build`: 0.4.2 -> 0.4.3 (✓ API compatible changes) <details><summary><i><b>Changelog</b></i></summary><p> ## `cargo-near` <blockquote> ## [0.13.3](cargo-near-v0.13.2...cargo-near-v0.13.3) - 2025-01-22 ### Other - update near-cli-rs to 0.18.0 (#293) - update `cargo near new` template `image` and `image_digest` ([#288](#288)) - update `cargo near new` template `image` and `image_digest` ([#283](#283)) </blockquote> ## `cargo-near-build` <blockquote> ## [0.4.3](cargo-near-build-v0.4.2...cargo-near-build-v0.4.3) - 2025-01-22 ### Fixed - remove from env CARGO_ENCODED_RUSTFLAGS for easier nested builds, simplify RUSTFLAGS computation rule (#289) ### Other - optimize out retriggering 2nd stage of build + of wasmopt stage in tests context (#292) - update `cargo near new` template `image` and `image_digest` ([#288](#288)) - unpin `cc` after issue resolution (#285) </blockquote> </p></details> --- This PR was generated with [release-plz](https://github.com/release-plz/release-plz/).
reason for this pr is that LazyLock initialization block
doesn't work to ensure tested contracts are built only once for
cargo nextest run
as cargo-nextest uses a process-per-test runner,and for usual
cargo test
workflows it may not be convenient/possible to unite all tests into a single test module, thus contracts' build will run at least once per each test module.This pr minimizes time spent on contracts' rebuilding after initial build, so that LazyLock init block isn't that much needed any more, but it depends on separating target folders of different contracts being tested similar to dj8yfo/neardevhub-contract@cbbf0ee to avoid partially rebuilding contracts starting with
near-sdk-macros
crate, if it's shared in common release profile when different contracts are in a workspace.this results in
instead of
on rebuilds.
and wasm-opt stage skipping was handled in e746699 . No file locks were added, it would still waste some cpu, if multiple builders enter the wasm-opt stage around the same time, but it does save on time and locks are perceived as unneeded complexity at this time.
vaguely related to Near-One/omni-bridge#184