fix(ci): make volcano-crd silently writes a 404 page instead of the PodGroup CRD

[sumedhcharjan]

make volcano-crd writes a file containing the text 404: Not Found instead of the PodGroup CRD, and exits 0 while doing it.

The version is derived from the volcano.sh/apis module:

https://github.com/kubeflow/trainer/blob/master/Makefile#L159-L161

VOLCANO_APIS_ROOT = $(shell go list -m -f "{{.Dir}}" volcano.sh/apis)
VOLCANO_VERSION = $(shell basename $(VOLCANO_APIS_ROOT) | cut -d'@' -f2)
VOLCANO_CRD_URL = https://raw.githubusercontent.com/volcano-sh/volcano/$(VOLCANO_VERSION)/config/crd/volcano/bases/scheduling.volcano.sh_podgroups.yaml

but the CRD is fetched from volcano-sh/volcano, which is a different repo. go.mod currently pins

volcano.sh/apis v1.13.1-0.20251028070205-46d20c0699e7

and that pseudo-version isn't a ref in either repo, so the URL 404s:

$ curl -sS -o /dev/null -w "%{http_code}" \
  https://raw.githubusercontent.com/volcano-sh/volcano/v1.13.1-0.20251028070205-46d20c0699e7/config/crd/volcano/bases/scheduling.volcano.sh_podgroups.yaml
404

curl -sSL has no --fail, so it writes the 404 body into the target file and returns success. The target passes, and manifests/external-crds/volcano/scheduling.volcano.sh_podgroups.yaml ends up containing the literal string 404: Not Found.

Nothing catches it downstream. The file is listed in CRDDirectoryPaths:

https://github.com/kubeflow/trainer/blob/master/test/integration/framework/framework.go#L63

ErrorIfCRDPathMissing: true doesn't help because the path does exist, it just has no CRD in it. And no integration test creates a volcano PodGroup today — the PodGroup specs use schedulerpluginsv1alpha1 — so the missing CRD never gets exercised.

I checked this rather than assuming: replacing the CRD file with the literal text 404: Not Found and running ginkgo ./test/integration/webhooks/... gives exactly the same result as with the correct file. So CI is green on master with a broken CRD, and will stay green until someone writes the first volcano test, at which point it fails for a reason that has nothing to do with their change.

I also checked whether the CRD could be pulled from volcano-sh/apis instead, so the version and the repo would match. It isn't there — config/crd/bases/, config/crd/volcano/bases/ and config/crd/ all 404 at both the pinned SHA and master.

So fixing it means deciding where the version comes from, and that's the part I'd rather not guess at:

1. Pin an explicit VOLCANO_VERSION in the Makefile, decoupled from the volcano.sh/apis pin (v1.13.0 resolves, I checked).
2. Derive the base release from the pseudo-version, i.e. v1.13.1-0.<ts>-<sha> means a commit after v1.13.0, so use v1.13.0.
3. Something else — vendor the CRD, or take it from the volcano Helm chart.

Either way curl should get --fail so a bad URL is loud instead of writing the error body into a YAML file.

Happy to send the PR once someone says which of those they'd prefer.

[Zohaibcode740]

Hi @sumedhcharjan,

I’d like to work on this issue. I can prepare a PR to make the volcano-crd target fail loudly on HTTP errors and fix the version handling.

Would you prefer:

1. pinning an explicit VOLCANO_VERSION (e.g. v1.13.0), or
2. deriving the Volcano release version from the volcano.sh/apis pseudo-version?

I’ll follow whichever approach you prefer.