readonlyRootfs prevents `run` from running
Input:
fs default() {
image "alpine:latest"
run "echo 1" with option {
readonlyRootfs
}
run "echo 2"
}
Output:
$ ./hlb run --log-output plain ./tests/bug.hlb
#1 compiling ./tests/bug.hlb
#1 DONE 0.0s
#3 docker-image://docker.io/library/alpine:latest
#3 resolve docker.io/library/alpine:latest
#3 resolve docker.io/library/alpine:latest 0.4s done
#3 DONE 0.4s
#3 docker-image://docker.io/library/alpine:latest
#3 CACHED
#2 /bin/sh -c echo 2
#2 0.101 2
#2 DONE 0.1s
Note: echo 1 is not in output
Hm, we'll have to investigate whether its a problem with HLB or LLB.
Yeah, looking at the code I dont see how it could be an HLB issue, so likely a LLB issue, I will try to dig deeper.
@coryb Thinking about it some more, this might be a confusing "feature not a bug". If the rootfs is readonly, then that command is inconsequential..? Though you may have a network call there that produces external side effects. Perhaps that's the intention anyway, to only use readonlyRootfs with read-write mounts.
Interesting, yeah, you are right, it is a confusing optimization.
If I rewrite to have an extra mount, then the command runs only if that mount is the target:
fs default() {
image "alpine:latest"
run "echo 1" with option {
readonlyRootfs
mount fs {scratch;} "/build" as buildOutput
}
run "echo 2"
}
Then if I just run default I get the same as before but if I run buildOutput it will execute echo 1 (and not echo 2)
But when I make that mount also readonly it also prevents it from executing:
fs default() {
image "alpine:latest"
run "echo 1" with option {
readonlyRootfs
mount fs {scratch;} "/build" with option {
readonly
} as buildOutput
}
run "echo 2"
}
Now if I run default it only runs the echo 2 and if I target buildOutput it runs an empty graph:
./hlb run --log-output plain -t buildOutput ./tests/bug.hlb
#1 compiling ./tests/bug.hlb
#1 DONE 0.0s
So this seems like it might be useful for providing optional outputs for similar targets, but it is a brain teaser.