Improve the experience for using this in e2e tests

[kannon92]

Motivation

In Kueue, we have discussed using this repo has a way to add testing for DRA support. There are a few problems with using this in e2e tests.

Problem 1

There is no release branch corresponding to each release so this will likely break if one tries to pull the main after a while. For Kueue, we would like to have testing for each k8s release (1.29, 1.30 and 1.31) and I expect this will fail when we transition to beta.

We can focus on supporting only 1.30 and 1.31 for now.

Problem 2

If one wanted to consume this in a e2e test, they must clone the library, build the driver, create a cluster with the DRA feature gate and helm install the driver into the cluster. Maybe as we publish release branches for this, we could consider publishing a chart or at least an image so other projects don't have the build the drivers on every test run.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[kannon92]

/remove-lifecycle stale

[nojnhuh]

I'm also interested in using the example driver in some new documentation (kubernetes/website#49079), where having a kubectl apply or helm install command would save the new docs from having to recreate the build steps listed in this repo.

[nojnhuh]

I'm happy to pick this up if I could get some pointers as to what the preferred hosting provider for a Helm chart would be. Using a GitHub Pages site or raw artifacts in GitHub has worked well enough for me before, but open to suggestions. @klueska @pohly Is that a sensible option here?

[pohly]

Kubernetes publishes images in its own registry. We should do the same for the example driver. Perhaps the image publishing process for CSI sidecars can be adapted, see https://github.com/kubernetes-csi/csi-release-tools/blob/master/SIDECAR_RELEASE_PROCESS.md#release-process, in particular step 11.

I don't think we have any central location for Helm charts. What you suggested sounds fine to me.

[nojnhuh]

Sounds good, I'll get started on that. Thanks!

/assign