Chore/consolidate e2e tests - #4383
Open
jimmykarily wants to merge 5 commits into
Open
Conversation
Ports the insecure-registry and partition-validation specs from
agent/tests/e2e into the monorepo's canonical suite at tests/, and
deletes the agent-side tree they came from.
The two specs test kairos-agent's manual-install behaviour, so they
belong next to the other install specs in tests/. Both drive real
VM boots via peg + qemu, same harness the monorepo suite already
uses.
tests/insecure_registry_test.go
- "fails at the pull without --allow-insecure-registries"
- "gets past the pull with --allow-insecure-registries"
Spins a plain-HTTP registry:2 on a free host port in BeforeAll,
re-tags a Hadron base image into it, and points the guest at
the QEMU host gateway via 10.0.2.2.sslip.io so the client picks
HTTPS by default and the --allow-insecure-registries flag
actually matters.
tests/partition_validation_test.go
- "fails before pulling when the partitions exceed the disk size"
- "gets past validation when the partitions fit the disk size"
Boots on a 20GB disk so the tooBigConfig's 30000MiB persistent
partition cannot fit; the fitting variant proves the guard does
not fire when it should not. Reuses the insecure-registry setup
for the oci: source since neither spec cares about TLS, they
only need a reachable source to exercise the pre-pull sanitize
step.
New CI cells (pr.yaml, master.yaml, release.yaml, all under
qemu-tests-core, variant core, amd64/generic):
- insecure-registry
- partition-validation
Deletions:
- agent/tests/e2e/ (5 test files + Dockerfile.inject + config.yaml
+ doc.go + .gitignore). The specs are now in tests/; the
Dockerfile.inject fixture that grafted a locally-built
kairos-agent onto a Hadron base is superseded by the monorepo
ISO artefact the reusable-qemu-test.yaml workflow already
downloads.
- agent/.github/ (dead pre-monorepo workflows and CODEOWNERS).
GitHub only reads .github/ at the repo root, so these have
been dormant since PR #4344 landed.
Refs #4367.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Signed-off-by: Dimitris Karakasilis <dimitris@karakasilis.me>
Ports the kcrypt-challenger e2e coverage that is not already in the
monorepo suite, drops the specs that duplicated existing coverage,
and deletes the kcrypt-side tree they came from along with the
pre-monorepo workflow that used to drive them.
Kept (ported to tests/encryption_advanced_test.go):
* remote-complete-workflow -- the monolithic TOFU + quarantine +
PCR/AK management + secret-reuse + multi-partition spec. Ported
verbatim as a single It; splitting it would double the wall clock
for no coverage gain, since each phase reuses the same VM boot
and enrollment state.
* remote-ek-only, remote-selective-pcr, remote-ek-reenroll,
remote-mixed-modes -- the selective-enrollment specs. Each is a
distinct scenario and was already its own Describe upstream; the
labels are prefixed with `encryption-` to line up with the
monorepo cell-selection convention (`.github/encryption-tests.sh`
invokes `ginkgo --label-filter "$LABEL"` and the reusable qemu
workflow branches on `startsWith(inputs.test, 'encryption-')`).
Dropped (already covered by tests/encryption_test.go):
* local-encryption, remote-auto, remote-static,
remote-https-pinned, remote-https-bad-cert -- one-to-one with
the monorepo suite's encryption-local, encryption-remote-auto,
encryption-remote-static, encryption-remote-https-pinned, and
encryption-remote-https-bad-cert cells.
* discoverable-kms -- was `XWhen`-disabled upstream with a TODO
about qemu bridge networking; not a regression to drop.
Helpers copied over next to the specs: installKairosWithConfigAdvanced,
rebootAndConnect, verifyEncryptedPartition, checkPassphraseRetrieval,
expectPassphraseRetrieval, expectPassphraseRetrievalWithError,
createSealedVolumeWithAttestation, updateSealedVolumeAttestation,
quarantineTPM, unquarantineTPM, deleteSealedVolume, secretExists,
cleanupTestResources. getSealedVolumeName is inlined -- the input is
always `tofu-<8 lowercase hex chars>`, 13 chars total, so the upstream
SafeKubeName truncation path is never taken and the helper reduces to
sprintf.
New CI cells added to qemu-tests-standard-encryption in pr.yaml,
master.yaml, and release.yaml:
- encryption-remote-complete-workflow
- encryption-remote-ek-only
- encryption-remote-selective-pcr
- encryption-remote-ek-reenroll
- encryption-remote-mixed-modes
Deletions in kcrypt/:
* tests/ (whole directory: 4 spec files + 4 asset YAMLs).
* scripts/ (only e2e-tests.sh, the wrapper .github/encryption-tests.sh
replaces at repo root).
* Dockerfile.kairos-image (built the pre-monorepo test ISO by cloning
the archived immucore + kairos-agent repos; only reachable through
the dead kcrypt/.github/workflows/e2e-tests.yml).
* .github/ (dead pre-monorepo workflows and issue template; GitHub
only reads .github/ at the repo root).
* Makefile: dropped the "Kairos Image Build" section (kairos-image /
kairos-iso / kairos-iso-uki / genkeys plus their build-arg
variables) and the "Cloud Init Datasource ISO" section
(datasource-iso). The kubebuilder scaffolding targets are left in
place; they are a distinct cleanup.
Refs #4367.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Signed-off-by: Dimitris Karakasilis <dimitris@karakasilis.me>
The two files under sdk/bundles were //go:build integration tests
covering the sdk bundle library's protocol/platform matrix (luet,
container://, docker://, run://; amd64/arm64/armv7 via WithPlatform;
local .tar fixtures under sdk/assets/). They never ran in CI --
sdk/Makefile invoked ginkgo without -tags integration, and no
absorbed or monorepo workflow ever built the -tags integration
binary. Keeping them in tree implied a coverage signal we did not
have.
The user-visible bundle behaviour is exercised at a higher level by
tests/bundles_test.go (Label `bundles`), which installs a real VM
against a cloud-config that pulls a bundle image the workflow just
pushed to quay. That cell is a hard gate on every PR, master push,
and release build, so the "does bundle install still work" contract
is enforced.
What was not covered by tests/bundles_test.go and is now formally
dropped:
* WithPlatform cross-arch pulls (amd64/arm64/arm/v7).
* The docker:// protocol path in the bundle library, distinct
from container://.
* The `type: run` semantic that drops manifests into
/var/lib/rancher/k3s/server/manifests/.
* Local .tar loading from disk (as opposed to remote pulls).
If those regress and the higher-level bundles cell does not catch it,
the right response is unit tests around the bundle library with
mocked fetchers, or a dedicated integration cell that we actually
invoke -- not a build tag no workflow references.
Deletes sdk/bundles/{bundle_test.go,bundles_suite_test.go} and the
sdk/assets/ fixtures directory (only consumers). sdk/bundles/bundles.go
(the source under test) is untouched.
Refs #4367.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Signed-off-by: Dimitris Karakasilis <dimitris@karakasilis.me>
tests/zfs_test.go (Label `zfs`) is not new -- it has been in the suite for years -- but no workflow matrix included the label, so it never actually ran in CI. Any regression in the zfs package bundling or in the kernel module load path would have shipped silently, since `zfs` is exercised nowhere else. The spec itself is a thin smoke: boots on an autoinstall config that lists the `zfs` module in rootfs stages, then asserts `zfs` appears in `lsmod`, creates a two-disk zpool over 1GB image files, writes a file, and reads it back. It exercises "zfs bundling still produces a loadable module + working userspace" and nothing beyond that -- if it flakes we can pull the cell out cheaply since it does not gate Kairos-specific behaviour. Bundling is still in place (kairos-init/pkg/values/packagemaps.go lists `zfsutils-linux` and alpineInit/mkinitfs.conf keeps `zfs` in the initramfs feature set), so on paper the spec should pass on the current hadron core ISO. Adds `zfs` to qemu-tests-core in pr.yaml, master.yaml, and release.yaml. Refs #4367. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Signed-off-by: Dimitris Karakasilis <dimitris@karakasilis.me>
pr.yaml is on pull_request_target, which runs master's copy of the workflow file rather than the PR's. That means the new qemu matrix cells this branch adds (insecure-registry, partition-validation, zfs, encryption-remote-complete-workflow, encryption-remote-ek-only, encryption-remote-selective-pcr, encryption-remote-ek-reenroll, encryption-remote-mixed-modes) never fire until this PR is merged and the cells are on master -- which is the wrong place to discover a broken port. Adds `pull_request` alongside `pull_request_target` so CI on this PR uses the PR's pr.yaml and exercises the new cells against the ported specs. Same transitional pattern the 2026-08-21 pr.yaml trigger flip used. This commit must be dropped before merge so master stays on pull_request_target only (git rebase -i and delete this commit, or revert it as a follow-up commit right before merge). Refs #4367. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Signed-off-by: Dimitris Karakasilis <dimitris@karakasilis.me>
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.
Summary
Each absorbed subdir came in with its own e2e or integration test tree (
agent/tests/e2e,kcrypt/tests,sdk/bundles) alongside the monorepo's canonical suite attests/. This PR ports the unique coverage intotests/, drops the specs that duplicated the monorepo suite, and deletes the per-subdir trees along with the dead pre-monorepo workflow files that used to drive them.Ported (verbatim, no reshape):
insecure-registryandpartition-validationfromagent/tests/e2e.remote-complete-workflowspec, kept as one monolithicItsince every phase reuses the same VM boot and enrollment state.ek-only,selective-pcr,ek-reenroll,mixed-modes), each as its ownDescribe.Dropped (already covered in
tests/encryption_test.go):local-encryption,remote-auto,remote-static,remote-https-pinned,remote-https-bad-cert.discoverable-kms, which was alreadyXWhen-disabled upstream with a TODO about qemu bridge networking.sdk/bundlesintegration suite: never wired to any CI workflow, and the user-visible bundle behaviour is exercised by thebundlescell intests/.Also wires the
zfscell into the qemu matrix. The spec was already intests/but no workflow ran it, so any regression in zfs bundling would have shipped silently.Deletions happen in the same commits that migrate the specs, so no relics are left in
agent/,kcrypt/, orsdk/: the per-subdir test trees, the subdir.github/workflow files,kcrypt/scripts/e2e-tests.sh,kcrypt/Dockerfile.kairos-image, and the dead "Kairos Image Build" and "Cloud Init Datasource ISO" sections ofkcrypt/Makefile. Thesdk/assets/*.tarfixtures go too since they had no other consumers.The last commit adds a transitional
pull_requesttrigger topr.yamlso CI on this PR actually exercises the new matrix cells (otherwisepull_request_targetreads master'spr.yamland the new cells never fire until after merge). It must be dropped before merge so master stays onpull_request_targetonly. Same pattern as the earlier trigger flip.Refs #4367.