feat(manifests): ship the vendored YAML and resolve it per version - #35
Merged
Conversation
The package carried generated TypeScript objects and no YAML at all, which made it unusable for its main purpose. Bring-up tooling applies manifests with kubectl apply -f: it needs files. Without them a consumer has no choice but to fetch the same YAML from GitHub releases at run time, which is the non-determinism this package exists to remove -- those downloads are rate limited per IP and die mid-transfer rather than failing cleanly. Three changes: The build now copies the vendored manifests into dist. Only the versioned copies: the unversioned <name>.yaml beside them is a build-time input for codegen and duplicates its own version directory byte for byte, so shipping both doubled the tarball for nothing. 6.4MB packed. getOperatorManifestPaths(id, version?) returns absolute paths in apply order. Order is encoded in the filenames -- Knative ships as three numbered parts because its CRDs must be established before serving-core creates custom resources of those kinds -- so returning them sorted means a caller cannot get that wrong by accident. An unknown version fails with the versions that do exist rather than silently returning the default. Knative now ships v1.15.0 and v1.22.1 together. This repo's e2e installs v1.15.0; downstream deploys v1.22.1. Carrying both lets each consumer ask for the version it runs, instead of one of them being wrong -- which is what the sources array was always for, and it unblocks the downstream migration without waiting on the v1.22.1 e2e investigation. getOperatorResources still ignores its version argument: the generated objects hold one resource set per operator, not one per version. Documented rather than silently ignored, and callers needing a specific version have the path API.
pyramation
force-pushed
the
feat/ship-manifest-files
branch
from
August 13, 2026 02:27
2478bc4 to
ed9dab8
Compare
Adding v1.22.1 to the manifests package changed what this suite installs, because it took the newest version. So a package carrying a version for a downstream consumer silently redirected a test at it -- and in this case at the version known to fail here. Newest is the wrong default once an operator can carry several versions for several consumers. A suite whose subject moves without anyone choosing it is not testing what its name says. knative-serving is pinned to v1.15.0, and the pin fails loudly if the package stops carrying it rather than quietly falling back. Everything else still tracks the newest, which is right for operators with a single version.
Nothing removed stale output, in three places, so a config change added files
without ever taking any away:
operators/ kept superseded versions, which is how cert-manager came to
advertise both v1.17.0 and v1.21.1 after a single-version bump,
and how ingress-nginx regenerated itself after being deleted
dist/ never cleaned, so a removed operator survived a rebuild
codegen reads operators/, so it faithfully reproduced both
Now: a full pull prunes operators not in the config and versions not in an
operator's sources, and the build cleans dist first. Verified by planting a
ghost operator and a ghost version and watching a plain --all remove both.
Pruning happens only on --all. A single-operator pull knows nothing about the
others and must not delete them.
Also drops the second Knative version this branch had added. The intent was to
carry v1.15.0 for this repo's e2e and v1.22.1 for downstream, which the package
is built for -- sources is an array. But getOperatorResources ignores its
version argument and returns whatever codegen emitted as the default, which is
the last version pulled. So adding v1.22.1 silently redirected every consumer
at it, including the e2e, which then reported installing v1.15.0 while applying
v1.22.1. I had documented that accessor as not honouring version and then
shipped a change that depended on it doing so.
The reason is recorded beside the operator, where someone would go to add a
second version. Doing it properly needs per-version resources in codegen.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The package shipped zero YAML — only generated TypeScript objects:
That makes it unusable for its main purpose. Bring-up tooling applies manifests with
kubectl apply -f— it needs files. Without them a consumer has no choice but to fetch the same YAML from GitHub releases at run time, which is exactly the non-determinism this package exists to remove.What changed
The build ships the manifests. Versioned copies only — the unversioned
<name>.yamlbeside them is a codegen input that duplicates its own version directory byte-for-byte, and shipping both doubled the tarball for nothing. 6.4MB packed (from 2.3MB).getOperatorManifestPaths(id, version?)returns absolute paths in apply order:Order is encoded in the filenames, so a caller can't get the CRD-before-core sequencing wrong by accident.
Knative ships both v1.15.0 and v1.22.1. This repo's e2e installs v1.15.0; downstream deploys v1.22.1. Carrying both lets each consumer ask for the version it actually runs — which is what
sources: Source[]was always for, and it unblocks the downstream migration without waiting on the v1.22.1 e2e investigation (constructive-planning#1630).One thing left honest rather than fixed
getOperatorResources(id, version?)still ignoresversion— the generated objects hold one resource set per operator, not one per version. It's now documented as such and points at the path API, rather than silently returning the wrong thing. Fixing it properly means embedding per-version docs in codegen, which is a bigger change and nothing needs it yet.