Allow for installation without cloning the repo.

[pravk03]

Currently we need clone the entire repository to install the driver, which can be inconvenient.

This PR publishes a mutable 0.0.0-latest tag for helm chart alongside the commit-specific version and updates the instructions in README to use this.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: pravk03

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [pravk03]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[pravk03]

@ffromani @fmuyassarov This is an optional QOL improvement, please feel free to push back if this is not necessary.

[AutuSnow]

I like the direction of this PR. Allowing users to install the driver without cloning the repository is a real usability improvement, especially for quick testing and staging deployments.

One thing I think we should be careful about is how we present the mutable 0.0.0-latest chart tag. Since it is mutable, I would prefer to describe it explicitly as a quickstart/staging convenience, not as the default reproducible installation path. For anything used in tests, debugging, or shared instructions, the pinned YYYYMMDD-gitsha chart versions seem safer.

Could we also confirm that the staging Artifact Registry allows overwriting/re-pushing the same Helm chart tag? Some OCI registry setups reject reusing an existing tag, and CI may not catch that until the publish job runs.

Minor doc point: the GitHub Releases install.yaml link is useful, but because install.yaml is already marked deprecated, maybe we should keep that section clearly framed as legacy-only so it does not compete with the Helm recommendation.

[fmuyassarov]

I think this makes sense and is needed. For developers like us, the local chart will still be useful, but having a chart version that can be pulled directly would likely be faster and more convenient.

One thing not to forget (for myself as well), for the official release charts, I think it would make more sense to use the production repository rather than staging. What do you think? In other words, the local chart can remain the default for development and testing, while the production repository would be the source for charts used in official releases.

helm install dra-driver-cpu oci://registry.k8s.io/dra-driver-cpu/charts/dra-driver-cpu --version ${VERSION} -n kube-system

based on this

skopeo list-tags docker://registry.k8s.io/dra-driver-cpu/dra-driver-cpu
{
    "Repository": "registry.k8s.io/dra-driver-cpu/dra-driver-cpu",
    "Tags": [
        "sha256-0ab4277b74a88655b3a344e1939551f815d9729f971459dafef94a4642da4c71.sig",
        "sha256-2c3eedbe4c9eed789d15c48cb92ab0b81969e30582098927bc0f8bac6310a535.sig",
        "sha256-2f81cbd98adbb24e0f9cb19fef432a80eeacde839cb35af1d41c279d8530182d.sig",
        "sha256-3b1ae241c65ed73381e1518e19ef996596086ae77f201d81e8bc1d35a6caae29.sig",
        "sha256-a74bef2b40dff4e0aeabe247bd6513152d013932749f8d32c0e39e5e8fb810af.att",
        "sha256-a74bef2b40dff4e0aeabe247bd6513152d013932749f8d32c0e39e5e8fb810af.sig",
        "v0.1.0"
    ]
}

[fmuyassarov]

Since this is from the HEAD, I guess it deserves a little note that it is not for official releases. Because, now the emphasize is on the avoiding the cloning but it may give an impression that this is for the official releases too, which we don't have yet + for the official releases we should use the production registry as I mentioned above.

[fmuyassarov]

can't we control the CHART_VERSION value from the test-infra to avoid duplication here?

[pravk03]

Thanks for the comments @AutuSnow @fmuyassarov.

Re:

One thing not to forget (for myself as well), for the official release charts, I think it would make more sense to use the production repository rather than staging

One thing I think we should be careful about is how we present the mutable 0.0.0-latest chart tag. Since it is mutable, I would prefer to describe it explicitly as a quickstart/staging convenience, not as the default reproducible installation path

Maybe it makes sense to wait for 0.2.0 (since we are close) and then add instructions to pull the chart directly from the production repos. Maybe we can hold off on this PR.

For local development, the current local chart instructions work fine. And for remote/clone-free installations, using official release versions from the production registry is probably the best path anyway. We can also avoid the mutable tag. WDYT ?

[fmuyassarov]

Thanks for the comments @AutuSnow @fmuyassarov.

Re:

One thing not to forget (for myself as well), for the official release charts, I think it would make more sense to use the production repository rather than staging

One thing I think we should be careful about is how we present the mutable 0.0.0-latest chart tag. Since it is mutable, I would prefer to describe it explicitly as a quickstart/staging convenience, not as the default reproducible installation path

Maybe it makes sense to wait for 0.2.0 (since we are close) and then add instructions to pull the chart directly from the production repos. Maybe we can hold off on this PR.

+1 from my side

For local development, the current local chart instructions work fine. And for remote/clone-free installations, using official release versions from the production registry is probably the best path anyway. We can also avoid the mutable tag. WDYT ?

+1 from my side

[pravk03]

/hold