Support `oci://` URL Scheme Prefixes in K8s Image References
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 10.1k
- Forks
- 413
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 6
Description
Feature Request: Support for oci:// URL Scheme Prefixes in K8s Image References
Use Case
I'm using Tilt to develop Istio WasmPlugins, which are custom modules that extend Istio's proxy functionality using an OCI image. In my ideal workflow, I can:
- Configure Tilt to build the image using
custom_build(https://docs.tilt.dev/api.html#api.custom_build). - Configure Tilt to replace the OCI image placeholder in the WasmPlugin manifest with the one generated by the
custom build usingk8s_kind(https://docs.tilt.dev/custom_resource.html). - As a result, whenever the
custom_builddeps are updated, Tilt will automatically build the Docker image,
push it to the registry, then update the Tilt resources.
Tilt is very close to working, but there is one minor issue. The WasmPlugin wants the image name to be prefixed by oci:// so that Istio knows to pull from OCI (instead of, file:// or https://, etc). However, the k8s_kind behavior of Tilt sees this string and throws an error, because oci:// is invalid in its image syntax.
Example WasmPlugin manifest:
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
name: my-plugin
spec:
url: oci://registry.example.com/my-wasm-plugin:1.0
Over time, I expect other use cases to run into this problem. For example:
- Flux and ArgoCD support
oci://for helm charts. - A handful of volume CSI drivers support mounting images as volumes using the
oci://syntax.
Root Cause
Tilt's current parse model (using distribution/reference) expects image references to follow the Docker format (e.g., registry.example.com/image:tag) and doesn't support URL schemes.
Proposed Solutions
Option 1: Wrapper Approach
Create a wrapper around the reference parser that preserves URL schemes:
- Add a
SchemeReferencetype ininternal/container/container.gothat wraps the standard Docker reference and preserves the scheme - Modify
ParseNamedto detect and strip URL schemes likeoci://before passing to the reference parser - Add a custom
FamiliarStringfunction that reattaches the scheme when converting back to string - Update dependent functions to use this scheme-aware parsing
Code references:
Pros:
- Doesn't require forking or modifying vendor libraries
- Lightweight change contained within Tilt's codebase
- Could handle other URL schemes like
docker://similarly
Cons:
- Adds complexity to the parsing logic
Option 2: Direct Vendor Library Modification
Modify the distribution/reference library directly:
- Update the regex patterns in
regexp.goto accept URL schemes - Modify
ParseNormalizedNamedto handle the schemes
Pros:
- Cleaner approach that handles it at the source, without Tilt having to own this complexity.
Cons:
- Requires modifying vendor code which makes dependency management harder
- Upstream project may not want this change (Docker image references technically don't support URL schemes)
Option 3: Custom Locator for WasmPlugins
Create a specialized ImageLocator implementation for WasmPlugins:
- Create a new
WasmPluginImageLocatorininternal/k8s/locator.gothat specifically handlesoci://prefixes - Register it through the
k8s_kindAPI for Istio WasmPlugin resources - This locator would have custom extraction and injection logic for these specific resources
Code references:
- ImageLocator interface in internal/k8s/locator.go
- k8s_kind implementation in internal/tiltfile/k8s.go
Pros:
- Contained to just the specific resource type
- Doesn't modify general-purpose code
Cons:
- Less reusable for other URL schemes
- More complex API surface
Recommendation
I recommend Option 1 (wrapper approach) as I imagine Option 2 is a much larger lift, and parsing oci:// prefixes may not be consistent with the goals of the distribution/reference lib as a whole.
Assuming this is the direction we go in, I can throw together a PR.
Related Resources
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with ParseNamed in internal/container/container.go and the image substitution logic in internal/k8s/image.go; compare their handling of the oci:// example from the issue. Review the ImageLocator interface in internal/k8s/locator.go if considering resource-specific handling. Done means k8s_kind accepts and preserves oci:// image references without the current invalid-syntax error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- devops, infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100