Repository navigation
oasis rofl build without builder should just fail on macOS #652
Description
This was suggested by one of our hackathoners:
Since oasis rofl build cannot work natively on macOS (and windows?) if no artifacts.builder is defined, it should simply crash saying sth like
Error: Building ROFL natively on {platform.os}_{platform.architecture} is not supported yet. Invoke the command inside a container:
docker/podman run --platform linux/amd64 --volume .:/src -it ghcr.io/oasisprotocol/rofl-dev:main oasis rofl build ... and any flags
Currently it goes on complaining that some library is missing etc.
Activity
kostko commentedon Nov 24, 2025
Why not say to configure the builder and/or make builder the default?
matevz commentedon Nov 24, 2025
That could also work, yeah. So when running
oasis rofl buildit would use podman/docker by default with the most recent builder version hardcoded in the Oasis CLI binary (and also adds thebuilder:field to the ROFL manifest)? And if you explicitly provide--no-containerflag, then the native environment is used.ptrus commentedon Nov 25, 2025
Makes sense to me.
kostko commentedon Nov 27, 2025
No.
When initializing new manifests it would use the latest builder by default.
When running
rofl upgradeit would add the builder.Same as with the other artifacts. It should not just use a random builder, it always must come from the manifest, as otherwise that will make stuff non-reproducible.
ptrus commentedon Nov 27, 2025
I've implemented draft versions of:
#656 (Matevz's suggestion)
and
#657 (Jernej's suggestion)
Probably the 2nd one is simpler and easier to reason about?
ptrus commentedon Nov 28, 2025
Actually, after re-evaluating these approaches, the issue is that the build cannot be made fully reproducible just using the builder as it's done now across Linux and macOS. That is because we do back-and-forth file transfers between the containers and the host.
I'm evaluating a new approach:
Instead of using the existing builder env wrappers, if a builder image is configured (and not
--no-container), we now automatically re-execute the entireoasis rofl buildinside that builder container (with the repo bind-mounted, env/args passed through, and a recursion guard) so all work runs on the container’s filesystem.Is it a bit hacky? But it's the only way to make this reproducible across different systems.
The alternative is to not allow native builds on non-linux, and instead always crash the
oasis rofl buildcommand, and output the appropriate docker run command to use instead. i.e.docker run <builder(from artifcats or default)> ...ptrus commentedon Nov 28, 2025
Depends on which option we prefer (on macOS):
oasis rofl buildworks, but is not reproducible with Linux (even if using artefacts.builder) Configure builder by default #657 implements thisoasis rofl buildonly works in cases where it's reproducible (so Linux, or within Docker on other platforms). It fails in other cases, suggesting the appropriate commandoasis rofl buildworks and produces reproducible imagesoasis rofl buildself-executes itself within Docker/Podman when on non-Linux. Basically the automated version of 2). But is a more complex/bigger changekostko commentedon Nov 28, 2025
Hm, I thought that the new tar-based variant fixed this? Which part is problematic, creating the tar archive on the host?