The shell translator rewrites test bodies and loses Bats reporting.
The unit lane needs complete TAP results and JUnit reports without
changing how live-cluster suites run.
Sourced production helpers still need a dash pass, and unit test bodies
need nounset without exporting shell options into subprocesses.
Assisted-by: LLM
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
templates/cdi-cr.yaml is ours. Against upstream's bare CDI object it
adds Helm templating for cloneStrategyOverride, uploadProxyURL and the
worker-pod podResourceRequirements, the ExpandDisks feature gate, a
CriticalAddonsOnly toleration, and the two RBAC documents that let a
tenant clone from the golden-image namespace. Five of those arrived by
hand. The toleration did not: it came in with the first commit, which
was byte-identical to upstream v1.58.0, and upstream dropped it at
v1.64.0 while this object kept it. That is the same divergence
`WebhookPvcRendering` records, running the other way. Either way
`wget -O templates/cdi-cr.yaml` was not refreshing a vendored file, it
was overwriting a first-party one -- the same loss as the
`rm -rf templates` this recipe stopped doing, arriving through the
fetch instead of the wipe.
What replaces it: the release the object is derived from is pinned
rather than resolved from GitHub's releases/latest redirect, and
`update` fetches it only to confirm the bytes still hash to a measured
sha256. Nothing is written under templates/. The next CDI bump that
changes the asset fails that check, which is the point -- upstream
moving its own defaults is when the local copy needs a human to
reconcile it, not an overwrite.
The download survives a mismatch, because reconciling one starts by
reading it.
RELEASE is v1.66.1, which is the release the operator manifest
vendors. ../kubevirt-cdi-operator decides what the platform deploys,
and it can move to another release without this file changing.
RELEASE is still set by hand rather than derived, because a
derived value is not a pin. What `update` adds is a comparison with the
cdi-operator image tag that package vendors, failing when the two
differ; without it the recipe's closing line would name a release the
platform may no longer run.
The difference from upstream is stated against v1.66.1 rather than as
a standing fact: upstream carried WebhookPvcRendering from v1.63.0
through v1.65.0 and dropped it by v1.66.0, and this object never
carried it, so the difference ran both ways for three releases and one
way after. The comment says to re-derive it at each bump for that
reason.
The `test:` target this package needed arrived separately, so what it
gains here is the `.PHONY` line that came without: hack/package.mk
declares only the targets it defines itself, so a file or directory
named test or update beside this Makefile would otherwise make that
target up to date and skip the recipe. The package also carried a
second, identical `test:` target, so make warned on every invocation
in it; that one is gone, and the comment above the remaining target is
what should stop another being added.
The suite is what makes the local delta checkable rather than
described, which is why the comment above `update` no longer lists
what the object adds: two copies of that list would diverge, and only
one of them can fail.
hack/package-update-templates.bats attributed `@#` recipe comments to
one named package. The tree writes them in more than one, and this
adds another, so the attribution goes; the case below it exercises
both spellings without naming who writes which. The header in that
file also lost its two-item example of first-party manifests. The
list named the two the recipe never wrote, and this change stops it
writing `cdi-cr.yaml` as well, so the example would have been short
by one the moment it landed.
Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
The update recipe in kubevirt-cdi opened with `rm -rf templates` and
then refetched one upstream manifest. The directory keeps two more
files -- the upload-proxy Ingress and TLSRoute -- that are written by
hand and never refetched, so the next CDI bump would drop upload-proxy
exposure from the chart while `make update` still exited 0. The clean
slate bought nothing either way: wget -O truncates the file it writes.
The recipe now creates the directory with `mkdir -p` and leaves the
rest of it alone, which is what kubevirt-operator moved to when it was
last bumped.
kubevirt-cdi-operator keeps its wipe. The same change there would be
for symmetry rather than for a loss, and it is not free: both its
patch calls resolve, so a hunk upstream has moved out from under
leaves templates/cdi-operator.yaml.rej, and gawk's inplace edit leaves
templates/cdi-operator.yaml.gawk.XXXXXX if it dies abnormally. Helm
renders every file under templates/, so the first fails the package
loudly and the second renders a duplicate object at exit 0. The wipe
is what takes both. Removing it wants that recipe restructured to
transform outside templates/ the way kubevirt-operator now does, which
is its own change. Until then the scan below is what watches that
package, with the limit the scan already documents: it reports a
tracked template whose stem the Makefile never mentions, so a name
that collides with something already written there, templates/
tolerations.yaml against the patches/tolerations.diff line, is
exempted. It catches the loss it was written for, not every loss.
The bats case scans every package Makefile rather than a pinned list,
so a first-party template added under a recipe that clears templates/
fails the commit that adds it instead of vanishing at the next bump.
A package's own NAME and NAMESPACE do not count as naming a file,
because a package called foo-bar would otherwise vouch for its
templates/bar.yaml with nothing writing it. A removal reaching into
another package is outside the scan's range, and the header records
the case in the tree that this leaves uncovered.
Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Myasnikov Daniil