Running nonexistent command with readonly root FS does not fail

[aaronlehmann]

➜  hlb git:(6f04a1d) ✗ cat bug.hlb
fs default() {
        image "alpine"
        run "doesnotexist" with option {
                readonlyRootfs
        }
}
➜  hlb git:(6f04a1d) ✗ go run ./cmd/hlb run bug.hlb
[+] Building 0.7s (2/2) FINISHED
 => resolve image config for docker.io/library/alpine:latest                                                                    0.4s
 => CACHED docker-image://docker.io/library/alpine:latest                                                                       0.0s
 => => resolve docker.io/library/alpine:latest                                                                                  0.2s
➜  hlb git:(6f04a1d) ✗ echo $?
0

Does the run get optimized out of the build graph because the readonly root FS means it can't have side effects? I'm not sure this is expected behavior, since it could have side effects outside the context of the filesystem.

cc @hinshun @coryb

[coryb]

yes, it is expected, it is optimized out since it can't possibly have side effects. You would need a writable mount for it not to be pruned.

[aaronlehmann]

What if it was a curl command making a call to an external API?

[coryb]

Yeah, not saying it is ideal, just the way buildkit works. I am not sure there is any practical usage of readonlyRootfs except possibly with an aliased mount. Buildkit is designed for artifact generation, not really for arbitrary execution. Perhaps we could get HLB to print a warning when readonlyRootfs is used without an aliased mount? We could probably also remove the option. The curl usage will work if we just don't explicitly tell buildkit that there are no outputs with readonlyRootfs.