in version.yaml we can specify both KBS_REPO#KBS_VERSION (kustomize code) and KBS_IMAGE#KBS_IMAGE_TAG.
there are implicit assumptions that kbs' kustomize scripts w/ version X work with kbs-image-tag version Y and kbs' kustomize "API" doesn't change. there are no guarantees for that. I'd suggest dropping KBS_IMAGE & KBS_IMAGE_TAG including the logic that tweaks those values in the test-provisioner code. CAA should deploy with what is the default in the kbs kustomize manifests (which should be the same revision as KBS_VERSION). In the niche case that someone wants to change that for an experimental build, they would:
clone the trustee repo
modify the kustomize manifests
specify their clone#branch in KBS_REPO#KBS_VERSION
the reasoning is that reducing the amount of knobs would make the tests more deterministic and reliable.
Describe the bug
in version.yaml we can specify both
KBS_REPO#KBS_VERSION
(kustomize code) andKBS_IMAGE#KBS_IMAGE_TAG
.there are implicit assumptions that kbs' kustomize scripts w/ version X work with kbs-image-tag version Y and kbs' kustomize "API" doesn't change. there are no guarantees for that. I'd suggest dropping KBS_IMAGE & KBS_IMAGE_TAG including the logic that tweaks those values in the test-provisioner code. CAA should deploy with what is the default in the kbs kustomize manifests (which should be the same revision as KBS_VERSION). In the niche case that someone wants to change that for an experimental build, they would:
the reasoning is that reducing the amount of knobs would make the tests more deterministic and reliable.
How to reproduce
n/a
CoCo version information
n/a
What TEE are you seeing the problem on
None
Failing command and relevant log output
No response