XeplosionTechnologies/.forgejo

Watch

Fork

You've already forked .forgejo

Code Issues 19 Pull requests Projects 5 Releases Packages Wiki Activity Actions

Add managed repository for validating CI/CD workflows #35

New issue

Open

opened 2026-09-07 22:09:17 +00:00 by Xeplosion · 0 comments

Xeplosion commented

2026-09-07 22:09:17 +00:00

Owner

Copy link

What problem or capability gap does this address?

Shared CI/CD workflows and managed template assets can affect multiple repositories after they are distributed through the .forgejo template system.

There is currently no dedicated, controlled repository whose purpose is to exercise those changes before broader distribution. This makes it possible for a workflow that is syntactically valid but behaviorally incorrect to reach active repositories before the failure is discovered.

A permanent validation target would provide a safe place to verify shared workflows, runner behavior, template propagation, and common failure paths before changes are promoted into normal use.

Desired outcome

Create a managed test repository dedicated to validating CI/CD and template-system changes.

The repository should:

use the same managed-template mechanisms as normal repositories;
exercise real Forgejo Actions behavior;
provide safe non-production test targets;
contain no production credentials;
be reusable whenever shared workflow or template changes need validation;
remain a validation consumer, not become another canonical source for workflows.

Proposed solution

Create a dedicated workflow-validation repository under XeplosionTechnologies.

Repository setup

Decide the repository name and scope.
Create the repository.
Apply appropriate branch protection.
Configure only test/non-production secrets and variables.
Ensure the repository cannot deploy to production.
Configure the appropriate Forgejo runner access.
Add a README explaining that the repository exists solely for workflow/template validation.

Managed-template integration

Create the repository from or connect it to the appropriate managed template.
Confirm shared files arrive through the normal template propagation path.
Confirm the repository does not become a second source of truth.
Define how a candidate workflow change reaches the validation repository before organization-wide distribution.
Define how validated changes are promoted back into the canonical workflow.

Validation coverage

Validate normal CI workflow execution.
Validate runner selection and routing.
Validate Forgejo variables.
Validate repository-scoped secrets where safe.
Validate shared-file/template synchronization.
Validate manual workflow dispatch.
Validate expected failure behavior.
Validate health-check behavior where applicable.
Validate rollback orchestration where applicable.
Validate release workflow behavior where applicable.
Confirm failures produce actionable logs.

Documentation

Document when use of the validation repository is expected.
Document the basic validation procedure.
Document what cannot safely be tested there.
Reference it from the CI/CD Wiki guidance.
Reference it from .forgejo workflow-maintenance documentation.

Alternatives considered

Test directly in active repositories. This provides realistic execution, but increases the blast radius of mistakes.

Rely only on workflow/YAML validation. This can catch syntax problems but cannot prove that the workflow behaves correctly in Forgejo Actions.

Use arbitrary template repositories as test targets. This lacks a stable, intentionally isolated validation environment.

Risk / compatibility considerations

The validation repository must not receive production credentials or production deployment authority.

It should exercise the same automation paths as managed repositories without creating a competing canonical workflow source.

Target / affected branch(es)

Supporting canonical .forgejo changes should target main.

The validation repository itself is a new repository rather than a change limited to an existing branch.

Additional context

This replaces the intent of the old workflow-test issue while accounting for the newer managed-template architecture.

Request checklist

I searched for an existing issue or discussion covering this request
I described the problem or capability gap, not only a proposed implementation

Workflow lifecycle

Triage

Kind/ classification confirmed
Issue validity reviewed and appropriate Reviewed/ label assigned
Priority/ assigned when appropriate
Implementation branch referenced on the issue through Forgejo when applicable
Information requirements resolved; no Status/Needs More Info remains
Status/Needs Triage removed before leaving Triage

Backlog

Issue is confirmed valid and accepted into the project backlog

To Do

Scope and expected outcome are sufficiently defined
Known prerequisites, dependencies, and required decisions are resolved or understood
Work has been deliberately selected as upcoming work

In Progress

Assignee or active owner identified when appropriate
Forgejo timer started when time tracking provides meaningful value
Relevant implementation, research, or work notes recorded as needed
Forgejo timer stopped when active work ends, pauses, or becomes blocked

Review Gate

Review requirement assessed based on complexity, criticality, reversibility, and impact
If review is required: moved to In Review and appropriate testing / validation performed
If review is required: review comment records what was reviewed, how it was validated, findings, and outcome
If review is not required: rationale is evident from the low-risk nature of the change

Completed

Acceptance criteria / intended outcome satisfied
Related PRs, commits, documentation, or external changes linked where applicable
Resolution is documented by a linked PR that closes the issue, or by a final issue comment explaining what changed, how it was resolved, and how it was verified
Follow-up work split into separate issues where appropriate
Any Forgejo timer is stopped and recorded time is final
Issue moved to Completed and closed

### What problem or capability gap does this address? Shared CI/CD workflows and managed template assets can affect multiple repositories after they are distributed through the `.forgejo` template system. There is currently no dedicated, controlled repository whose purpose is to exercise those changes before broader distribution. This makes it possible for a workflow that is syntactically valid but behaviorally incorrect to reach active repositories before the failure is discovered. A permanent validation target would provide a safe place to verify shared workflows, runner behavior, template propagation, and common failure paths before changes are promoted into normal use. ### Desired outcome Create a managed test repository dedicated to validating CI/CD and template-system changes. The repository should: * use the same managed-template mechanisms as normal repositories; * exercise real Forgejo Actions behavior; * provide safe non-production test targets; * contain no production credentials; * be reusable whenever shared workflow or template changes need validation; * remain a validation consumer, not become another canonical source for workflows. ### Proposed solution Create a dedicated workflow-validation repository under `XeplosionTechnologies`. ### Repository setup * [x] Decide the repository name and scope. * [x] Create the repository. * [ ] Apply appropriate branch protection. * [ ] Configure only test/non-production secrets and variables. * [ ] Ensure the repository cannot deploy to production. * [ ] Configure the appropriate Forgejo runner access. * [ ] Add a README explaining that the repository exists solely for workflow/template validation. ### Managed-template integration * [ ] Create the repository from or connect it to the appropriate managed template. * [ ] Confirm shared files arrive through the normal template propagation path. * [ ] Confirm the repository does not become a second source of truth. * [ ] Define how a candidate workflow change reaches the validation repository before organization-wide distribution. * [ ] Define how validated changes are promoted back into the canonical workflow. ### Validation coverage * [ ] Validate normal CI workflow execution. * [ ] Validate runner selection and routing. * [ ] Validate Forgejo variables. * [ ] Validate repository-scoped secrets where safe. * [ ] Validate shared-file/template synchronization. * [ ] Validate manual workflow dispatch. * [ ] Validate expected failure behavior. * [ ] Validate health-check behavior where applicable. * [ ] Validate rollback orchestration where applicable. * [ ] Validate release workflow behavior where applicable. * [ ] Confirm failures produce actionable logs. ### Documentation * [ ] Document when use of the validation repository is expected. * [ ] Document the basic validation procedure. * [ ] Document what cannot safely be tested there. * [ ] Reference it from the CI/CD Wiki guidance. * [ ] Reference it from `.forgejo` workflow-maintenance documentation. ### Alternatives considered **Test directly in active repositories.** This provides realistic execution, but increases the blast radius of mistakes. **Rely only on workflow/YAML validation.** This can catch syntax problems but cannot prove that the workflow behaves correctly in Forgejo Actions. **Use arbitrary template repositories as test targets.** This lacks a stable, intentionally isolated validation environment. ### Risk / compatibility considerations The validation repository must not receive production credentials or production deployment authority. It should exercise the same automation paths as managed repositories without creating a competing canonical workflow source. ### Target / affected branch(es) Supporting canonical `.forgejo` changes should target `main`. The validation repository itself is a new repository rather than a change limited to an existing branch. ### Additional context This replaces the intent of the old workflow-test issue while accounting for the newer managed-template architecture. ### Request checklist - [x] I searched for an existing issue or discussion covering this request - [x] I described the problem or capability gap, not only a proposed implementation ### Workflow lifecycle ### Triage - [x] `Kind/` classification confirmed - [x] Issue validity reviewed and appropriate `Reviewed/` label assigned - [x] `Priority/` assigned when appropriate - [x] Implementation branch referenced on the issue through Forgejo when applicable - [x] Information requirements resolved; no `Status/Needs More Info` remains - [x] `Status/Needs Triage` removed before leaving Triage ### Backlog - [x] Issue is confirmed valid and accepted into the project backlog ### To Do - [x] Scope and expected outcome are sufficiently defined - [x] Known prerequisites, dependencies, and required decisions are resolved or understood - [x] Work has been deliberately selected as upcoming work ### In Progress - [x] Assignee or active owner identified when appropriate - [x] Forgejo timer started when time tracking provides meaningful value - [x] Relevant implementation, research, or work notes recorded as needed - [x] Forgejo timer stopped when active work ends, pauses, or becomes blocked ### Review Gate - [ ] Review requirement assessed based on complexity, criticality, reversibility, and impact - [ ] If review is required: moved to **In Review** and appropriate testing / validation performed - [ ] If review is required: review comment records what was reviewed, how it was validated, findings, and outcome - [ ] If review is not required: rationale is evident from the low-risk nature of the change ### Completed - [ ] Acceptance criteria / intended outcome satisfied - [ ] Related PRs, commits, documentation, or external changes linked where applicable - [ ] Resolution is documented by a linked PR that closes the issue, or by a final issue comment explaining what changed, how it was resolved, and how it was verified - [ ] Follow-up work split into separate issues where appropriate - [ ] Any Forgejo timer is stopped and recorded time is final - [ ] Issue moved to **Completed** and closed

Xeplosion added the

Rows
Columns