Skip to content

Conversation

@chrysn
Copy link
Member

@chrysn chrysn commented Nov 4, 2025

Frankly, I have no clue how variable the output will be, esp. as we're using a nightly compiler.

I'd like to keep running those builds in CI for a bit as more PRs come in, just to get a feel of whether or not they are all already easily reproducible. Biggest factor will likely be the nightly version, but that's hard to test as there are not so many older Rust nightlies with which the now memory-reduced builds work in the first place.

(Also, no CI steps are active yet, thus draft).

@chrysn chrysn force-pushed the reproduce branch 9 times, most recently from 085228d to f5700a9 Compare November 4, 2025 01:53
@chrysn
Copy link
Member Author

chrysn commented Nov 4, 2025

As both this action and my local builds should run on the same Rust nightly, and there are diffs, there is apparently some non-reproducibility. Where (and whether it's my setup or something that actually needs fixing in one of the tools) is to be found.

@chrysn chrysn marked this pull request as ready for review November 4, 2025 02:22
@anlavandier
Copy link
Contributor

In my (limited) testing it seemed to be fairly reproducible given that we use the same nightly. The version of Wasmtime is also to be considered.

That is the only place where Ariel-buildable binaries are produced, and
this way, Ariel's crates-io overrides do not affect the VMs.
As Ariel OS's .cargo/config.toml is now out of the way, those do not
contain unrelated overrides any more.
@chrysn
Copy link
Member Author

chrysn commented Nov 4, 2025

Rebased onto main after the recent merges, so that things could work even after merging.

Ad reproducibility, the artifact generated by the CI run does differ in some files; diffoscope output looks like it's the ordering of the functions. As all involved systems are on latest nightlies and latest wasm-tools and wasmtime is pinned now in ./precompile_wasm.rs, I'm a bit clueless as to where else the variation could come from.

@anlavandier
Copy link
Contributor

To be fair I didn't diff the files and just compared the binary size and saw that it stayed the same. Does the wc -c size and/or the size of the sections stay the same in your testing ?

@chrysn
Copy link
Member Author

chrysn commented Nov 4, 2025

Size is the same. Diff says "yeah there's a difference". Sensible output is best obtained from diffoscope, which was built for Debian to show why a build is not reproducible, it automatically drills down as far as it can into any structures to show sensible deltas, while also showing differences that would not show at all in a plain "convert to readable format" diff.

@anlavandier
Copy link
Contributor

Could this be OS-related. Also is there a way for me to test things ? I guess that the simplest way is to copy the actions workflow and open another PR ?

@chrysn
Copy link
Member Author

chrysn commented Nov 4, 2025

If you arrive at the same binaries as I do, yes, a new PR is the easiest way to run tests on GitHub CI. One easier way to reproduce it may be to run in containers, but so far I don't have any data point as to whether things built in Docker would act like on my machine or like GitHub actions.

@anlavandier
Copy link
Contributor

Which exact nightly did you use ? I'm seeing size diffs so that's probably because I didn't use the exact nightly you used

@chrysn
Copy link
Member Author

chrysn commented Nov 4, 2025

I used 2025-11-02 I think, but right, by now that could be different, so we should probably pin that for reproducible builds (but update frequently).

@anlavandier
Copy link
Contributor

After getting the nightly right, I don't get any diffs so that's promising

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