`oasis rofl build` without `builder` should just fail on macOS

[matevz]

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.

[kostko]

Why not say to configure the builder and/or make builder the default?

[matevz]

Why not say to configure the builder and/or make builder the default?

That could also work, yeah. So when running oasis rofl build it would use podman/docker by default with the most recent builder version hardcoded in the Oasis CLI binary (and also adds the builder: field to the ROFL manifest)? And if you explicitly provide --no-container flag, then the native environment is used.

[ptrus]

Makes sense to me.

[kostko]

So when running oasis rofl build it would use podman/docker by default with the most recent builder version hardcoded in the Oasis CLI binary

No.

When initializing new manifests it would use the latest builder by default.

When running rofl upgrade it 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]

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]

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 entire oasis rofl build inside 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 build command, and output the appropriate docker run command to use instead. i.e. docker run <builder(from artifcats or default)> ...

[ptrus]

Depends on which option we prefer (on macOS):

1. oasis rofl build works, but is not reproducible with Linux (even if using artefacts.builder) Configure builder by default #657 implements this
2. oasis rofl build only works in cases where it's reproducible (so Linux, or within Docker on other platforms). It fails in other cases, suggesting the appropriate command

• This is a simple change

3. oasis rofl build works and produces reproducible images

• I think the only way to achieve this realistically is that oasis rofl build self-executes itself within Docker/Podman when on non-Linux. Basically the automated version of 2). But is a more complex/bigger change

[kostko]

Hm, I thought that the new tar-based variant fixed this? Which part is problematic, creating the tar archive on the host?