cargo-near build whole workspace with one docker instance

[frolvanya]

Add a support to build reproducible-wasm files for all workspace at once. Right now if we have multiple contracts sharing the same dependecies we need to rebuild all of them multiple times from scratch since every build uses clean docker state. It would be great to be able to run cargo near build reproducible-wasm at the root of workspace and if project has a reproducible build info in toml file it would be automatically included to the build process and use only one docker instance to build all contracts at once

Here's an example where it can drastically improve build time: https://github.com/Near-One/omni-bridge/actions/runs/13065597964/job/36457334849

[dj8yfo]

@frolvanya would it be simpler to run builds in parallel in ci with matrix with multiple executors ?

[frolvanya]

@dj8yfo I tried running it parallel using -j option in make command and it reduced time by 2 mins, but it's not a solution. We still waste ton of resources by recompiling the same packages all over again in multiple dockers and it doesn't matter if we're doing it in parallel or not. Also, it'd improve UX, we're using makefile to compile all contracts, I'd like to opt out of this workflow by calling a simple cargo near build in the root of the workspace (just like I do with regular cargo build when I want to compile all projects all together)

[frolvanya]

Are there any technical challenges on implementing the same workflow as cargo build with workspaces?

[dj8yfo]

@frolvanya sure there are. Right now it sounds more like a random collection of words + phantasy, than a technical way to solve it. There might be a way to do it while preserving reproducubility, and there might not.
I'd rather not invest time into it right now, making it more complex and adding a trillion of edge cases to juggle around. It's simple to ensure reproducibility right now because it's always the same clean state, there's really not much that could go wrong. Adding a shared docker volume for it might work well, might not, might work well apparently at first, than raise more problems than it solved.
Why do you need reproducible build for local dev at all? I thought it was only a ci thing for dev/staging/production deployments. Is it?

[frolvanya]

Why do you need reproducible build for local dev at all?

I think there's a misunderstanding, where did I say that I need a reproducible build for local development? We're using it in a workflow to update releases page where we store our contracts

[dj8yfo]

using -j option in make command and it reduced time by 2 mins, but it's not a solution

I suggested not running in parallel on one vm, but splitting it in ci to multiple vm-s with matrix config. Like running different make commands for each parallel job, not running make in parallel in a single job

[frolvanya]

Oh, yes, this will work, but it looks more like a workaround instead of a solution to me

[frolvanya]

Right now it sounds more like a random collection of words + phantasy, than a technical way to solve it.

Well, I just proposed a feature (@frol suggested me to do this), it's up to cargo-near team to decide if this is possible and how to do it. I'm not working in cargo-near team, so I can't give you a step-by-step instruction how to do it

[dj8yfo]

@frolvanya you could throw in an rfc on how nep-330 1.3.0 would look like, or how it alternatively could be fitted to fully comply with with 1.2.0

[dj8yfo]

so I can't give you a step-by-step instruction how to do it

k

[dj8yfo]

We still waste ton of resources by recompiling

Without a ready technical solution on how to solve it, it's just a speculation that it's a waste of ton of resources