Enforce complete validation in the shared Forgejo runner flow #13

New issue

Open

opened 2026-11-01 20:11:33 +00:00 by viacheslavshuka · 0 comments

viacheslavshuka commented

2026-11-01 20:11:33 +00:00

Owner

Every pull request needs required validation before merge. Outside contributors use the same automatic runner flow while validation jobs remain unable to access production credentials or resources.

Scope

Add versioned Forgejo Actions workflows and repository protection settings. Inspect the installed runner, host, and container-runtime configuration before claiming the production-access restriction is enforced.

Acceptance criteria

Changes to main require a pull request and passing required checks. Contributor pull requests require maintainer approval before merge. No separate approval is required to execute each revision.
Document short-lived work branches merged into main. Development deployments follow validated main commits, with no separate long-lived development branch.
Contributors use the operator's runner flow. The change does not add contributor-specific runners, a separate CI system, or a separate deployment pool.
Validation jobs cannot obtain deployment credentials or access production resources. Checks include persisted workspaces, container runtime access, caches, logs, and cross-job residue.
Record the actual infrastructure evidence supporting those restrictions. If the installed setup cannot enforce them, report the concrete blocker rather than claiming isolation or changing the shared runner topology.
Each run uses independent disposable application and PostgreSQL environments with Testcontainers, synthetic data, and test credentials. Cleanup runs after success, failure, and cancellation.
Every pull request runs the complete applicable suite. Required jobs cover static checks, tests, coverage, mutation, contracts, generated output, frontend checks, image checks, and selected security scans as introduced.
Independent checks can run concurrently. Changed-file filters cannot omit applicable suites. A failed, missing, canceled, or incomplete required check cannot produce a successful aggregate result.
The actual squashed main commit receives complete required validation. Pull-request results for another commit cannot authorize deployment.
Conventional Commit pull-request titles become squash commit messages and release-note inputs. Local working commits remain unrestricted. The sole maintainer does not require a second person's approval.
Workflow actions use immutable commit references. Containers use digests. Executable tool inputs use pins or committed lockfiles.

Validation

Exercise a trusted branch and an outside-contributor revision through the same flow. Use nonsecret test markers to check denied credential/resource access and cross-job residue. Confirm a failing required job blocks merge and development deployment. Verify cancellation cleans disposable resources.

Dependencies

#5: Configure shared offline commit checks. The first required CI gate needs the shared static-check commands.

Every pull request needs required validation before merge. Outside contributors use the same automatic runner flow while validation jobs remain unable to access production credentials or resources. ## Scope Add versioned Forgejo Actions workflows and repository protection settings. Inspect the installed runner, host, and container-runtime configuration before claiming the production-access restriction is enforced. ## Acceptance criteria - Changes to `main` require a pull request and passing required checks. Contributor pull requests require maintainer approval before merge. No separate approval is required to execute each revision. - Document short-lived work branches merged into `main`. Development deployments follow validated `main` commits, with no separate long-lived development branch. - Contributors use the operator's runner flow. The change does not add contributor-specific runners, a separate CI system, or a separate deployment pool. - Validation jobs cannot obtain deployment credentials or access production resources. Checks include persisted workspaces, container runtime access, caches, logs, and cross-job residue. - Record the actual infrastructure evidence supporting those restrictions. If the installed setup cannot enforce them, report the concrete blocker rather than claiming isolation or changing the shared runner topology. - Each run uses independent disposable application and PostgreSQL environments with Testcontainers, synthetic data, and test credentials. Cleanup runs after success, failure, and cancellation. - Every pull request runs the complete applicable suite. Required jobs cover static checks, tests, coverage, mutation, contracts, generated output, frontend checks, image checks, and selected security scans as introduced. - Independent checks can run concurrently. Changed-file filters cannot omit applicable suites. A failed, missing, canceled, or incomplete required check cannot produce a successful aggregate result. - The actual squashed `main` commit receives complete required validation. Pull-request results for another commit cannot authorize deployment. - Conventional Commit pull-request titles become squash commit messages and release-note inputs. Local working commits remain unrestricted. The sole maintainer does not require a second person's approval. - Workflow actions use immutable commit references. Containers use digests. Executable tool inputs use pins or committed lockfiles. ## Validation Exercise a trusted branch and an outside-contributor revision through the same flow. Use nonsecret test markers to check denied credential/resource access and cross-job residue. Confirm a failing required job blocks merge and development deployment. Verify cancellation cleans disposable resources. ## Dependencies - [#5: Configure shared offline commit checks](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/5). The first required CI gate needs the shared static-check commands. ## Related work - [#15: Enforce Python behavior coverage and mutation checks](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/15) - [#9: Enforce frontend correctness and report runtime performance](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/9) - [#10: Generate and verify OpenAPI and the TypeScript client](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/10) - [#26: Package and serve the website and API from one image](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/26) - [#17: Scan tracked files and complete Git history for secrets](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/17) - [#30: Block vulnerable dependencies and unsafe container configuration](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/30) - [#31: Scan the disposable authenticated API with ZAP](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/31)

viacheslavshuka referenced this issue

2026-11-01 20:11:36 +00:00

Scan tracked files and complete Git history for secrets #17

viacheslavshuka referenced this issue

2026-11-01 20:11:47 +00:00

Block vulnerable dependencies and unsafe container configuration #30

viacheslavshuka referenced this issue

2026-11-01 20:11:48 +00:00

Scan the disposable authenticated API with ZAP #31

viacheslavshuka referenced this issue

2026-11-01 20:11:51 +00:00

Deploy validated main images to development #34