con un clic
forge
forge contiene 13 skills recopiladas de C5C3, con cobertura ocupacional por repositorio y páginas de detalle dentro del sitio.
Skills en este repositorio
Audit Status condition coverage end-to-end for every forge operator — every condition type set by a sub-reconciler must appear in that operator's subReconcilerConditionTypes map (so metrics labels resolve), every sub-reconciler must have a unit test, and every condition the operator's reference docs document must be set somewhere in code. Use when asked to check condition coverage, after adding or renaming a sub-reconciler or a condition type, or when a Prometheus condition_type label suddenly shows up as UNKNOWN.
Audit the forge documentation for drift against the implementation — the architecture/docs/ chapters vs the operator code, the docs/ user-facing reference vs the deploy/ infrastructure stack. Use when asked to check documentation drift, after adding or removing a sub-reconciler, status condition, operator binary, or infrastructure component, or before tagging a release.
Audit whether every Keystone / c5c3 CR fixture under tests/e2e/ and tests/e2e-chaos/ still validates against the *current* CRD schema — no removed Spec field is still referenced, every fixture's apiVersion / kind matches a real CRD, every invalid-cr fixture is reachable from a Chainsaw test, and the existing verify-invalid-cr-fixtures generator stays in sync with its hand-edited outputs. Use when asked to check fixture drift, after editing the Keystone CRD or the validating webhook, or before a release.
Audit the forge Go workspace for dependency-version drift between the operators/<op>/go.mod files and internal/common/go.mod — controller-runtime, k8s.io/api, k8s.io/apimachinery, k8s.io/client-go, the Go directive, and the toolchain pin must stay in lockstep so the workspace builds the same versions everywhere. Use when asked to check workspace deps, after running `go get` in one module, or after Renovate bumps controller-runtime in only one of the modules.
Audit whether every OpenStack release under releases/<version>/ is fully wired through the forge repo — the mandatory release config files, the per-release Tempest config directory the CI matrix generator hard-requires, the per-release basic-deployment e2e variant, the default-release references in deploy/kind/, hack/, and ci.yaml, the Renovate regression tests, the upgrade-path e2e suites, and the version-pattern lockstep across CRD marker, webhook, and release.ParseRelease. Use when asked to check release wiring, after adding or removing a releases/<version>/ directory, or before a release when a stale default tag or an orphan Tempest directory would fail the pipeline.
Audit whether every pinned version in the forge repo — OpenStack release tags under releases/<version>/source-refs.yaml, shell-script VERSION constants under hack/, kind / FluxCD HelmRelease versions under deploy/kind/ and deploy/flux-system/, and tool-version pins in Makefile + .github/workflows — is covered by either a native Renovate manager or a customManager rule in renovate.json with a paired packageRules entry, and that tool pins duplicated between the Makefile and ci.yaml stay in lockstep. Use when asked to check Renovate coverage, after adding a new pinned dependency, or when a previously-bumped pin silently stopped receiving updates.
Audit whether every onboarded OpenStack service stays in structural lockstep with the keystone reference implementation across the five onboarding layers — container image under images/<svc>/, service operator under operators/<svc>/, CI/e2e/deploy wiring, ControlPlane integration in operators/c5c3/, and the documentation set under docs/. Use when asked to check service parity, after merging or while reviewing a service-onboarding PR, or when a second (or later) service starts drifting from the scaffolding conventions keystone defines.
Audit whether every CR validation rule stays in parity across its four representations — the declarative kubebuilder markers and XValidation/CEL rules in operators/<op>/api/ and internal/common/types, the validating webhook in *_webhook.go, the webhook unit tests, and the invalid-cr e2e rejection corpus under tests/e2e/<op>/invalid-cr/. Use when asked to check validation parity, after adding or changing a validation rule or webhook, or after a CEL rule had to be demoted to webhook-only enforcement.
Diagnose a failing chainsaw e2e job in the forge CI — resolve the failed run, pull the failed-step logs and JUnit/diagnostic evidence, map the failure back to the suite directory under tests/, classify it against the known flake patterns, and reproduce it locally against a kind cluster. Use when a CI e2e job fails (e2e-infra, e2e-operator, e2e-chaos, e2e-prometheus, e2e-controlplane, e2e-operator-upgrade, tempest), when asked to debug a chainsaw suite, or when reproducing an e2e failure locally.
Analyze and prepare the addition of a new OpenStack release (e.g. 2026.2) into forge — inventory the touch points the auto-discovery does not cover (release config files under releases/<version>/, the Tempest config directory the CI matrix generator hard-requires, per-release e2e variants, constraint overrides), and walk the decision points: moving the default release, extending the upgrade-path tests, and retiring an old release. Use when asked to add or onboard a new OpenStack release, to bump the release matrix, or to remove an old release from the repo.
Analyze and prepare the onboarding of a new OpenStack service into forge — inventory the five layers (container image, service operator, CI/e2e, ControlPlane integration, documentation) against the Keystone reference implementation, check what keystone scaffolding must be generalized into internal/common first, and draft the phased meta issue ready to be split into sub-issues. Use when asked to onboard or add a new OpenStack service (e.g. Glance, Nova, Neutron, Placement), to prepare a service meta issue, or to assess readiness for the next service operator.
Audit whether every forge operator CRD is in sync across its three representations — the Go +kubebuilder source under operators/<op>/api/, the controller-gen output under operators/<op>/config/crd/bases/, and the Helm chart copy under operators/<op>/helm/<op>-operator/crds/. Use when asked to check CRD drift, after editing a *_types.go file or a kubebuilder marker, or before a release to catch a CRD that the cluster will reject because the schema is older than the controller.
Audit SPDX / REUSE compliance across the forge source tree — every *.go, *.sh, hand-authored YAML, and CI workflow file should carry matching SPDX-FileCopyrightText and SPDX-License-Identifier headers, every license referenced in a header has a corresponding text under LICENSES/, and architecture/REUSE.toml stays well-formed. Use when asked to check SPDX or REUSE coverage, after adding a new source file, or before tagging a release where SAP supply-chain audits require clean REUSE output.