mrmeku
commented
1 year ago This is the only tricky bit of dropping rules_docker entirely https://github.com/bazelbuild/rules_k8s/blob/7fe8176fecc0082753c97deaf0f18d434d5a8b1a/k8s/object.bzl#L68
Other than that, rules_docker can be easily replaced by rules_oci for packaging or by inlining helper functions which are currently imported from rules_docker which @alexeagle has already mostly taken care of with a PR.
Translating the above into something that's compatible with rules_oci will be a bit different since oci_image produces a directory artifact as its only output where as rules_docker seems to have shipped with a provider which made it easier to consume in the bazel layer.
However, that artifact will always follow the OCI image-spec https://github.com/opencontainers/image-spec/blob/main/image-layout.md
It seems practical to teach rules_k8s resolver how to consume directory artifacts that fit that layout rather than consuming that layout in the bazel layer. Following that, the above line would translate into pointing the resolver to one or more image directories and leaving it to the go program to understand how to interpret different possible directory structures (starting with OCI image layouts to start and adding more as needed to the resolver)
realtimetodie
Because it is in "minimal maintenance mode" https://github.com/bazelbuild/rules_docker#status and also I think it's a layering violation, it shouldn't matter to rules_k8s how the images were constructed. At most, it might want to load some Provider symbols from rules_docker just to have a deeper understanding of the inputs it receives.
Related to #722