railiance-enablement/registry/capabilities/capability.railiance.ci-enablement.md

id	name	summary	owner	status	domain	tags	maturity	external_evidence	discovery	availability	relations	evidence	consumer_guidance	promotion_history
capability.railiance.ci-enablement	Railiance Developer Enablement And CI/CD Templates	S4 Developer Enablement layer of the Railiance OAS Stack — reusable CI/CD workflow templates, developer portal paths, platform templates, SDKs, and buildpacks, using forge capabilities without owning forge runtime.	railiance-enablement	draft	financials	railiance ci-cd developer-enablement forgejo	discovery availability current target confidence rationale D3 D4 medium SCOPE.md places this repo precisely at S4 in the Railiance OAS Stack, explicitly scoped to reusable CI/CD templates and enablement tooling while using (not owning) forge capabilities. current target confidence rationale A2 A3 high Ships real, reusable Forgejo Actions workflow templates (container-build-push.yaml, container-build-push-multirepo.yaml, ci-smoke.yaml) plus `tools/promote-repo-to-forgejo.sh` — directly relevant tooling for the ecosystem-wide Gitea-to-Forgejo transition (REUSE-WP-0019).	completeness reliability level confidence basis satisfied_expectations broken_expectations out_of_scope_expectations C2 low scope_vs_intent_and_consumer_expectations reusable Forgejo Actions CI/CD workflow templates already in production shape a repo-promotion-to-forgejo script directly usable for the platform-wide forge transition level confidence basis known_reliability_risks R1 low consumer_quality_signals templates are workflow YAML, not a packaged/versioned artifact; consumption is copy/reference rather than dependency-managed	intent includes excludes assumptions use_cases research_memos Give Railiance repos reusable CI/CD templates and developer-enablement tooling (including forge-promotion tooling) without each repo owning the forge runtime or runner substrate itself. reusable Forgejo Actions CI/CD workflow templates repo-to-forgejo promotion tooling developer portal/platform template scope (per SCOPE.md) forge runtime and runner substrate ownership (see railiance-forge)	current_level target_level current_artifacts target_artifacts consumption_modes A2 A3 workflows/container-build-push.yaml workflows/ci-smoke.yaml tools/promote-repo-to-forgejo.sh ci workflow template (copy/reference) cli (promote-repo-to-forgejo.sh)	depends_on supports related_to	documentation tests consumer_feedback bug_reports incidents SCOPE.md workflows/ci-smoke.yaml	recommended_for not_recommended_for known_limitations Railiance repos needing reusable Forgejo Actions CI/CD templates, or any repo executing a Gitea-to-Forgejo promotion needs for owning forge runtime/runner infrastructure itself (see railiance-forge) templates are consumed by copy/reference, not as a versioned dependency

Railiance Developer Enablement And CI/CD Templates

Overview

railiance-enablement is the S4 Developer Enablement layer of the Railiance OAS Stack: reusable CI/CD workflow templates and developer-enablement tooling, including a promote-repo-to-forgejo.sh script directly relevant to the ecosystem-wide Gitea-to-Forgejo transition tracked in REUSE-WP-0019.

Assessment notes

Discovery

SCOPE.md places this repo precisely at S4 in the Railiance OAS Stack, explicitly scoped to reusable CI/CD templates and enablement tooling while using (not owning) forge capabilities.

Availability

Ships real, reusable Forgejo Actions workflow templates (container-build-push.yaml, container-build-push-multirepo.yaml, ci-smoke.yaml) plus tools/promote-repo-to-forgejo.sh — directly relevant tooling for the ecosystem-wide Gitea-to-Forgejo transition (REUSE-WP-0019).

Completeness

First-pass honest assessment from the REUSE-WP-0017 coverage campaign (reuse-surface). No external consumer feedback exists yet; levels reflect scope-vs-intent documentation quality, not internal code quality.

Reliability

No production consumer telemetry exists yet; reliability level is intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.

Promotion checklist

• ID follows capability.<domain>.<name> pattern
• Maturity enums match specs/CapabilityMaturityStandard.md
• external_evidence is populated separately from maturity
• Relations reference valid capability IDs (none yet)
• Index entry added in registry/indexes/capabilities.yaml