Why
Part of the self-service kubeconfig bootstrap initiative (tracking issue TBD, linked once created). The unit tests in each sub-issue cover components in isolation; this ties the whole flow together on a real (kind) cluster, matching the project's existing make test-e2e approach.
Scope
Extend test/e2e/ with scenarios:
- Full happy path: create
User with spec.email set → token issued → (mock SMTP) email sent → kubeuser init → working kubeconfig → kubectl calls succeed with the new identity.
kubeuser sync after a forced rotation → local kubeconfig updates, new cert works, old one no longer does.
kubeuser sync against a deleted User → correctly blocked, clear message.
kubeuser sync against an autoRenew: false User past expiry → correctly blocked, clear message.
- Resend-annotation flow: annotate → old token invalidated → new token/email issued.
Acceptance criteria
Depends on
#101, #102, #103, #104, #105, #106, #107, #108
Why
Part of the self-service kubeconfig bootstrap initiative (tracking issue TBD, linked once created). The unit tests in each sub-issue cover components in isolation; this ties the whole flow together on a real (kind) cluster, matching the project's existing
make test-e2eapproach.Scope
Extend
test/e2e/with scenarios:Userwithspec.emailset → token issued → (mock SMTP) email sent →kubeuser init→ working kubeconfig →kubectlcalls succeed with the new identity.kubeuser syncafter a forced rotation → local kubeconfig updates, new cert works, old one no longer does.kubeuser syncagainst a deletedUser→ correctly blocked, clear message.kubeuser syncagainst anautoRenew: falseUserpast expiry → correctly blocked, clear message.Acceptance criteria
make test-e2eDepends on
#101, #102, #103, #104, #105, #106, #107, #108