First end-to-end test of the ansible-run Configuration on a real cluster (cicd-xplane, k3s, 2026-05-29). The headline features work — Composition renders the wrapped Object, EnvironmentConfig defaults are applied, deriveReadiness gates correctly, and a real playbook (sthings.baseos.setup against a target host) ran to success with the XR going Ready=True only after the PipelineRun Succeeded=True.
These findings came up and are worth addressing:
1. XRD field defaults silently override EnvironmentConfig values
The documented precedence is XR spec → EnvironmentConfig → -D option → hardcoded default. But the API server materializes XRD default: values as XR spec values before the Composition runs, and the kcl module reads them as oxr.spec.<field>. So any field with an XRD default can never be overridden by the EnvironmentConfig.
Observed: an AnsibleRun that omitted ansibleWorkingImage still rendered the XRD default sthings-ansible:13.5.0-test instead of the EnvironmentConfig's 11.11.0. Same for gitRevision (XRD default main). Fields with no XRD default (gitPath, storageClass) correctly took the EnvironmentConfig value.
Decision needed: for fields meant to be EnvironmentConfig-overridable (ansibleWorkingImage, gitRevision, …), drop the XRD default: and rely on the kcl module's own fallback. Otherwise document clearly that those fields are not env-overridable.
2. Example EnvironmentConfig pins storageClass: openebs-hostpath
cicd/ansible-run/examples/environmentconfig.yaml sets storageClass: openebs-hostpath. Clusters without that provisioner (e.g. cicd-xplane, which only has local-path) leave the Tekton workspace PVC Pending forever and the PipelineRun never schedules. Consider a more portable default (or document that storageClass is environment-specific and must be set per cluster — which is exactly the EnvironmentConfig's purpose).
3. Default storageSize (20Mi) is too small for real runs
The kcl module default storageSize is 20Mi. A repo clone + collection install needs more; runs are flaky/fail at that size. Consider bumping the default to a few hundred Mi, or documenting a realistic minimum.
4. Published ghcr package is stale
ghcr.io/stuttgart-things/crossplane-configurations/ansible-run:v0.1.0 still pins kcl-tekton-pr:0.4.6 (pre-EnvironmentConfig / pre-deriveReadiness). main now pins 0.6.0. The Configuration should be re-published. (A v0.1.1 was pushed to ghcr during testing but is private — needs a visibility flip or a clean release.)
Test environment (for reference)
- Cluster
cicd-xplane (kubeconfig ~/.kube/cicd-crossplane.yaml), tested via a ttl.sh dev package pinning kcl-tekton-pr:0.6.0.
- A transient first PipelineRun failure (
exit 255 / pod Unknown after a successful git clone; node healthy, no OOM/disk pressure) cleared on retry — noting in case it recurs.
🤖 Generated with Claude Code
First end-to-end test of the
ansible-runConfiguration on a real cluster (cicd-xplane, k3s, 2026-05-29). The headline features work — Composition renders the wrappedObject, EnvironmentConfig defaults are applied,deriveReadinessgates correctly, and a real playbook (sthings.baseos.setupagainst a target host) ran to success with the XR goingReady=Trueonly after the PipelineRunSucceeded=True.These findings came up and are worth addressing:
1. XRD field defaults silently override EnvironmentConfig values
The documented precedence is
XR spec → EnvironmentConfig → -D option → hardcoded default. But the API server materializes XRDdefault:values as XR spec values before the Composition runs, and the kcl module reads them asoxr.spec.<field>. So any field with an XRD default can never be overridden by the EnvironmentConfig.Observed: an AnsibleRun that omitted
ansibleWorkingImagestill rendered the XRD defaultsthings-ansible:13.5.0-testinstead of the EnvironmentConfig's11.11.0. Same forgitRevision(XRD defaultmain). Fields with no XRD default (gitPath,storageClass) correctly took the EnvironmentConfig value.Decision needed: for fields meant to be EnvironmentConfig-overridable (
ansibleWorkingImage,gitRevision, …), drop the XRDdefault:and rely on the kcl module's own fallback. Otherwise document clearly that those fields are not env-overridable.2. Example EnvironmentConfig pins
storageClass: openebs-hostpathcicd/ansible-run/examples/environmentconfig.yamlsetsstorageClass: openebs-hostpath. Clusters without that provisioner (e.g.cicd-xplane, which only haslocal-path) leave the Tekton workspace PVCPendingforever and the PipelineRun never schedules. Consider a more portable default (or document that storageClass is environment-specific and must be set per cluster — which is exactly the EnvironmentConfig's purpose).3. Default
storageSize(20Mi) is too small for real runsThe kcl module default
storageSizeis20Mi. A repo clone + collection install needs more; runs are flaky/fail at that size. Consider bumping the default to a few hundred Mi, or documenting a realistic minimum.4. Published ghcr package is stale
ghcr.io/stuttgart-things/crossplane-configurations/ansible-run:v0.1.0still pinskcl-tekton-pr:0.4.6(pre-EnvironmentConfig / pre-deriveReadiness).mainnow pins0.6.0. The Configuration should be re-published. (Av0.1.1was pushed to ghcr during testing but is private — needs a visibility flip or a clean release.)Test environment (for reference)
cicd-xplane(kubeconfig~/.kube/cicd-crossplane.yaml), tested via a ttl.sh dev package pinning kcl-tekton-pr:0.6.0.exit 255/ podUnknownafter a successful git clone; node healthy, no OOM/disk pressure) cleared on retry — noting in case it recurs.🤖 Generated with Claude Code