gitea-admin/simple-private-codecollection

Files

T

stewartshea 31ac475c97 Update Crossplane GCP Bucket generation rules to use preferred API version

Modified the generation rules for Crossplane GCP Buckets to omit the version in resource type definitions, allowing the use of the API server's preferred version (currently v1beta2). Updated documentation to reflect this change and clarify version pinning for schema stability.

Changes include:
- Updated YAML generation rules to remove explicit versioning.
- Revised documentation to explain the implications of omitting versioning and the preferred version usage.

This enhances resilience across CRD upgrades and simplifies the configuration for users.

2026-06-30 21:55:36 -04:00

.runwhen

Update Crossplane GCP Bucket generation rules to use preferred API version

2026-06-30 21:55:36 -04:00

README.md

Initial scaffold: generation-rule-only Crossplane Bucket example

2026-06-30 21:51:04 -04:00

README.md

gcp-bucket-crossplane-health

A generation-rule-only codebundle. It has no sli.robot, no runbook.robot, and no meta.yaml. It ships:

File	Role
`.runwhen/generation-rules/gcp-bucket-crossplane-health.yaml`	Tells workspace-builder to discover every Crossplane `Bucket` (`storage.gcp.upbound.io/v1beta1`) in the cluster and generate one SLX per bucket.
`.runwhen/templates/gcp-bucket-crossplane-health-slx.yaml`	Jinja template for the `ServiceLevelX` resource.
`.runwhen/templates/gcp-bucket-crossplane-health-sli.yaml`	Jinja template for the `ServiceLevelIndicator`. Points at `rw-generic-codecollection/k8s-kubectl-cmd/sli.robot`.
`.runwhen/templates/gcp-bucket-crossplane-health-taskset.yaml`	Jinja template for the `Runbook` (TaskSet). Points at `rw-generic-codecollection/k8s-kubectl-cmd/runbook.robot` in JSON-issue mode.

How it works

workspace-builder loads this codecollection and reads the generation rule.
The rule declares resourceTypes: [buckets.storage.gcp.upbound.io/v1beta1]. RunWhen Local's Kubernetes indexer expands that spec into plural=buckets, group=storage.gcp.upbound.io, version=v1beta1, calls list_cluster_custom_object, and stores each Bucket in the registry.
The matchRules predicate matches every Bucket by name (regex .+).
For each match, the rule emits an SLX with three output items (slx, sli, runbook). Each output item is rendered from the corresponding Jinja template.
The SLI and Runbook templates set codeBundle.repoUrl to the internal airgap URL for rw-generic-codecollection, and pathToRobot to k8s-kubectl-cmd/{sli,runbook}.robot. That's where the actual runtime lives — this codecollection ships only the discovery and templating logic.

Health scoring

SLI — the KUBECTL_COMMAND runs kubectl get bucket ... -o json, pipes through jq to compute the fraction of .status.conditions[] whose status == "True", and pushes that number (0.0 to 1.0) as the metric. A healthy Crossplane Bucket has Ready=True and Synced=True, producing an SLI of 1.0.
TaskSet — the same generic bundle in JSON-issue mode. The jq expression emits { issuesIdentified: true|false, issues: [...] }. Each condition whose status is not True becomes one issue with a severity (higher for Ready), a reproduce_hint, and human-readable next_steps.

Why this pattern is useful

Reuse over rewrite: no need to fork or maintain another robot file.
Small blast radius: a private repo like this one holds just the organization-specific discovery logic and messaging.
Fast iteration: change the jq filter and the workspace-builder picks it up on the next reconcile — no runner image rebuild required.