5.4 KiB
GitOps validation
The orb owns .github/workflows/gitops.yml. The consumer keeps only the immutable caller generated by generate_auxiliary_workflow.py gitops --ref <orb-commit> at .github/workflows/validate.yml.
One native job downloads Kustomize 5.7.1 with its pinned official SHA-256 and renders every Kustomization, including bases, overlays and proxy declarations. Missing configurations or a failed render fail the job. Rendered resources are discarded rather than logged or uploaded because they may contain Secrets. This checks rendering, not Kubernetes schema compatibility or cluster health. No cluster access or publication credentials are required.
The caller runs on main pushes and pull requests without path filters, so a required check always reports. Superseded PR runs are canceled. Feature pushes do not create duplicate jobs. Remove the old Circle pipeline only after the native job passes on the consumer, then disable obsolete Circle build requests and require the observed native check with no human review.
For marketing-website-cd, the prior Circle job only printed Hello World. Its former production role moved to KofTwentyTwo/cluster-gitops; validation does not re-enable that retired deployment path.
The shared registry includes marketing-website-cd and voyage-cd. Daily enrollment recognizes their canonical main-branch caller without creating Circle configuration. Recognition requires a signed immutable worker pin matching the supported worker, a complete source tree, and no additional Circle or GitHub workflows. Enforcement requires the GitHub Actions app-bound gitops / validate gate and preserves existing branch rules. Unavailable private-repository protections remain an explicit enforcement failure; recognition alone is not enforcement.
Documentation repositories with shell automation
Use the canonical repository-policy manifest with shell_checks: true for
repositories containing documentation, YAML/JSON, Mermaid source, and shell tools.
The shared job remains one small executor with no publication or deployment.
It installs ShellCheck only for this opt-in and checks every tracked .sh file
with bash -n and ShellCheck at warning severity; scripts are never executed.
Mermaid files are treated as UTF-8 documentation, not rendered or syntax-validated.
Application manifests and other executable languages still require a build profile.
Homebrew distribution taps
The homebrew-tap profile takes only tap (lowercase owner/name) and formula.
One small job in a digest-pinned Homebrew container validates the exact checkout,
reads all OS/architecture variants, fetches their binaries with checksum verification,
then installs and tests the Linux formula. It does not publish or update formulae.
macOS downloads are verified, but this Linux job does not execute macOS binaries.
Application template acceptance
The application-template profile renders the checked-out template through pinned
qctl code and a checksum-verified catalog. It runs transforms but never post-generation
hooks, then performs Maven verify on the generated application with all its tests.
The renderer and Maven dependencies are cached; test reports and the generated JAR
are retained. This is acceptance of a generated consumer, not Maven publication.
Only the standard profile, orb version, and default branch are consumer settings.
The coordinator also recognizes qctl on main/develop and the approved .github, business-platform, MCP-RAG and IntelliJ callers on main. It verifies each complete workflow inventory, canonical caller, signed immutable orb pin and matching shared worker source before recognizing the repository. Native verification gates bind to the GitHub Actions app; release-only jobs are not merge requirements. No CircleCI caller is added to these native consumers. qctl requires its shared tests; the native binary job is push-only, and full platform release builds retain their existing shared-worker policy.
Existing classic branch protections without a required-status-check section gain an additive shared ruleset. Signing, reviews, history and access restrictions remain unchanged, and a subsequent reconciliation verifies the effective ruleset.
The same daily pass manages CircleCI's native autocancel-builds setting for
canonical repository-policy, homebrew-tap, application-template, and
marketing consumers. Marketing must retain main as its default branch;
environment deployment remains main-only. CircleCI excludes default-branch,
scheduled and rerun workflows from automatic cancellation. This avoids a custom
cancellation job and does not add executions to consumer pipelines.
The pass uses the existing orb-publishing context on the trusted orb main branch.
It changes only the cancellation flag, checks for source movement before writing,
and verifies preservation of all other flags. Its separate
result.circle-settings.json artifact records missing credentials/API access,
unconverted sources and profiles needing cancellation-policy review explicitly.
Publication-heavy profiles are not changed until their non-default release
semantics are reviewed; a successful reconciliation pass does not certify them.
Because cancellation is project-wide, eligibility requires every discovered current main/develop branch to be canonical and use a reviewed profile. An unresolved branch or an unreviewed publishing profile prevents enabling the flag, regardless of branch order. The report lists all observed profiles.