The tested v0.0.5 path installed from the verified self-hosted bundle, reported the expected runtime identity and completed an Independent Kubernetes Validation OperationRun. All ten operation steps succeeded, the downloaded report matched the recorded SHA-256 hash, temporary permissions were revoked and cleanup completed. This is evidence for one defined release, cluster, mode and point in time—not a general production certification.
The practical question behind the test
Self-service becomes credible only when an authorized user can start a supported workflow and the platform can show what happened from admission to cleanup. A green button or an API response is not enough. Installation identity, execution boundary, ordered steps, result integrity and permission removal all have to agree.
The objective of this run was therefore deliberately narrow: install the published ClusterPilot v0.0.5 distribution through its official entry point, verify the running release and then start Independent Kubernetes Validation through the normal product interface. The result had to remain reviewable without relying on a developer terminal or a short-lived CI artifact.
Release
ClusterPilot v0.0.5 with the published candidate source identity and signed distribution assets.
Validation baseline
Catalog 0.0.3, Sonobuoy v0.57.5 and Kubernetes v1.36.2 in the supported release contract.
Operation result
Ten successful OperationSteps with temporary authorization, agent execution, result registration and cleanup.
Test result
8 passed, 0 failed and 7,578 skipped tests in the selected validation mode.
Start from a signed and release-scoped baseline
The run used the published v0.0.5 release line associated with source commit 95525862911a12cbbaf4151c0d9078dd140f4a6f. The canonical distribution consists of the self-hosted bundle, Helm chart, their matching checksums and signatures, and the release signing public key. Candidate, eligibility, promotion and release evidence are separate supporting records rather than substitutes for those installable assets.
The validation capability is also release-scoped. The signed catalog entry declares the supported tool and Kubernetes baseline, so runtime admission does not depend on an undocumented previous cluster result. This removes a circular condition while keeping the exact version, mode and target requirements explicit.
Install through the same path a technical evaluator receives
The official entry point was executed directly from the downloaded v0.0.5 self-hosted bundle. Preflight-only and dry-run completed before installation. The installation then migrated a fresh PostgreSQL database, started the API and database services and completed verify-only successfully.
The running API reported version 0.0.5 and the expected candidate commit. Its image digest matched the digest pinned by the signed release evidence. That check matters because a healthy service alone does not prove that the reviewed software is the software currently running.
- 01
Verify
Check bundle and chart checksums and signatures with the published release key.
- 02
Preflight
Validate host, configuration and required dependencies without changing the environment.
- 03
Dry-run
Review the intended installation path before applying it.
- 04
Install
Migrate the fresh database and start the release-pinned services.
- 05
Verify runtime
Confirm health, version, source identity and the signed API image digest.
Start Independent Kubernetes Validation as a normal user workflow
After publication, a new validation was started through the regular ClusterPilot interface. The selected cluster's lifecycle agent—not the release workflow and not the ClusterPilot hosting cluster—executed the pinned Sonobuoy workload. The OperationRun connected authorization, execution, collection and cleanup to one durable record.
All ten OperationSteps completed successfully. The sequence included temporary permission creation, lifecycle-agent execution, result registration, permission revocation and final cleanup. This is the important self-service boundary: the user initiates an approved operation, while the platform controls its scope and preserves the outcome.
Temporary authorization
The run received the bounded access needed for the selected validation workflow.
Agent execution
The lifecycle agent assigned to the target cluster executed the pinned workload.
Result registration
Status, test counts and report evidence were attached to the OperationRun.
Revocation and cleanup
Temporary permissions were removed and cleanup completed as ordered steps.
Trusted Kubernetes tools. Installed from one place.
ClusterPilot brings essential platform tools into your cluster through clear workflows. Status, progress and results stay visible.
Check the result, not only the green status
The selected validation mode reported 8 passed tests, 0 failed tests and 7,578 skipped tests. Skipped tests are not silently converted into successes: they remain visible as part of the exact Sonobuoy result. The pass statement applies to the selected mode and its executed tests, not to every possible Kubernetes test.
The report recorded SHA-256 0b22979d579526f1df4c517c20291b3fc5ba10ce6011205478ab5b896e950a44. A separately downloaded copy produced the same hash as the API and UI record. That equality shows that the report reviewed after the run is byte-for-byte the report registered by ClusterPilot.
What this case study shows
The evidence closes a specific end-to-end path: signed release assets can be installed, the runtime can be matched to the reviewed release and an authorized user can start a supported validation that returns a verifiable report and cleans up its temporary access.
The boundary is just as important as the success. The result is tied to v0.0.5, the selected cluster, catalog entry, Kubernetes version, validation mode and execution time. A different environment still needs its own prerequisites, acceptance and production decision.
Proven
The tested installation, runtime identity, OperationRun sequence, report match and cleanup completed as documented.
Clearly linked
The result stays connected to the exact cluster, provider, network and release.
Reviewable
Platform, QA and operations teams can inspect one ordered record instead of reconstructing it from separate systems.
Ready for review
Platform, QA and operations teams review the same result together.
Use the same evidence model in a customer pilot
A useful ClusterPilot evaluation begins with one cluster and one measurable operation. Define the release, target, success criteria, access and cleanup expectation. After the run, compare the saved result with the downloaded report.
This keeps a pilot honest. The goal is not to demonstrate every visible feature, but to prove one operational path that the customer's platform, QA and operations teams can repeat and review together.
- 01
Choose one target
Use a ClusterPilot-managed Ready cluster.
- 02
Fix the baseline
Record the exact release, catalog entry, Kubernetes version and validation mode.
- 03
Define success
Agree on admission, execution, report integrity, permission revocation and cleanup criteria.
- 04
Run through the product
Start and follow the supported operation through the normal interface.
- 05
Review together
Compare UI, API and downloaded report evidence before deciding on the next scope.
Questions about the ClusterPilot validation case study
Where did Sonobuoy run?+
The selected ClusterPilot-managed target cluster's lifecycle agent executed the pinned Sonobuoy workload. Sonobuoy did not run in the release workflow or on the ClusterPilot hosting cluster.
Do 7,578 skipped tests mean the run failed?+
No. The selected mode reported 8 passed, 0 failed and 7,578 skipped tests. The skipped count remains part of the result and prevents the limited executed scope from being misrepresented as every possible Kubernetes test.
What does a passing run show?+
It shows the result for the selected release, cluster, mode and time window in one clear report.
What should a customer verify in a pilot?+
Verify signed installation assets, runtime identity, all ordered steps, result counts, report hash, permission revocation and cleanup.