make oci_image() accept a file for workdir

[lazcamus]

This clones much of the same logic as entrypoint and friends. Also refactor docstring a little to illuminate "wrapper vs the rule" and the dual typed args.

[lazcamus]

I used this to clone the language rule's "set a default workdir for language targets" logic from rules_docker

My intent is to extract some of my local changes and add default entrypoint and workdir setting to https://github.com/aspect-build/bazel-examples/tree/main/oci_python_image

[lazcamus]

also worth noting that it breaks backwards compatibility: workdir = "/root" has to change to workdir = ["/root"]

[thesayyn]

I don’t think it makes sense to have an attribute that takes an array for a single value. Doesn’t make sense from public api standpoint.

[jjmaestro]

@lazcamus I love the idea to be able to use the output of a target by just passing the label but I agree with @thesayyn re. not using an array. Also, per the Dockerfile spec, WORKDIR only has a single argument. IMHO it maps much better to just one string.

Following your notation (which I also think is great and clarifies the wrapper-vs-rule) I'd prefer if workdir could be STR_OR_LABEL. I think that brings in all the goodies from your PR and still maintains a more natural API that's aligned with the Dockerfile spec.

[lazcamus]

On Sun, Sep 1, 2024 at 2:22 AM Sahin Yort ***@***.***> wrote: I don’t think it makes sense to have an attribute that takes an array for a single value. Doesn’t make sense from public api standpoint.

Makes sense. I'll up my skylark skills and re-work it :)

…

Message ID: ***@***.***>

[lazcamus]

I pushed a commit that makes workdir a STRING_OR_LABEL, so PTAL

The reason I originally ended up on the list is b/c it's easy to check with types in a macro, and everybody else was using lists so it kinda blended in 😆

There is no "is this string a valid label?" check in macro context, so I did some hacky string matching.

It comes with the corner case of: what do you do if you get "foo" ? It's a valid target (I'd use ":foo" but not everybody is me). "foo" is also a valid relative workdir (I also only use absolute workdirs). I chose label for this weird in-between case, but could see it either way. A workaround if you want "foo" to be a relative workdir string is to use "./foo", which seems OK 🤷

[lazcamus]

CI status seems like a runner failure, hopefully intermittent?

ERROR: /home/runner/work/rules_oci/rules_oci/examples/dockerfile/BUILD.bazel:18:11: BuildDocker examples/dockerfile/base [for tool] failed: (Exit 1): buildx failed: error executing BuildDocker command (from target //examples/dockerfile:base) bazel-out/k8-opt-exec-ST-13d3ddad9198/bin/examples/dockerfile/buildx build ./examples/dockerfile --builder builder-docker ... (remaining 1 argument skipped)
error: dial unix /run/buildkit/buildkitd.sock: connect: no such file or directory
ERROR: listing workers for Build: failed to list workers: Unavailable: connection error: desc = "error reading server preface: EOF"
INFO: Elapsed time: 20.426s, Critical Path: 10.96s
INFO: 363 processes: 308 internal, 40 linux-sandbox, 15 local.
ERROR: Build did NOT complete successfully

[thesayyn]

i am afraid only possible solution here is to allow string only from the macro since we can't distinguish between string vs label despite best efforts. I believe it was one of the big mistakes of bazel not making it apparently obvious between string vs label from use-site perspective.