DarkHelm.org/plex-playlist
Public Access
4
0
Fork 0
Code Issues 62 Pull Requests 1 Actions 9 Packages Projects 1 Releases Wiki Activity

feat(ci): enforce runtime-validation image separation #69

Open
darkhelm wants to merge 2 commits from feature/issue-59-runtime-validation-separation into main
pull from: feature/issue-59-runtime-validation-separation
merge into: DarkHelm.org:main
Conversation 0 Commits 2 Files Changed 7 +499 -11
darkhelm commented 2026-06-19 19:03:32 -04:00
Owner
Copy Link

Summary

Implements issue #59 by enforcing a hard boundary between CI validation tooling and deployable runtime images.

This PR:

  • Adds automated deployable-runtime boundary checks in CI.
  • Verifies deployable backend/frontend artifacts are free of CI/development tooling.
  • Documents runtime-vs-validation ownership and enforcement behavior.

What Changed

CI workflow enforcement

  • Updated .gitea/workflows/docker-build-main.yaml to:

    • Checkout additional verification inputs (Dockerfile.backend, Dockerfile.frontend, scripts, backend/frontend directories).
    • Run scripts/check-dockerfile-boundaries.sh.
    • Build deployable runtime images (Dockerfile.backend, Dockerfile.frontend --target production).
    • Run scripts/verify-deployable-image-purity.sh against both images before publishing CICD image.

  • Updated .gitea/workflows/cicd-checks.yaml to add:

    • dockerfile-boundary-check job.
    • Boundary validation execution inside the CICD validation image.

New enforcement scripts

  • Added scripts/check-dockerfile-boundaries.sh:

    • Ensures deployable Dockerfiles do not reference CICD image paths (cicd-base, CICD_BASE_IMAGE, Dockerfile.cicd*, etc.).
    • Ensures deployable Dockerfiles do not include disallowed CI-only tooling tokens.
    • Enforces runtime base expectations:
      • Backend: python:3.14-slim
      • Frontend production target: nginx:alpine

  • Added scripts/verify-deployable-image-purity.sh:

    • Baseline binary checks for disallowed tooling.
    • Backend-specific deep checks:
      • Python module import probes for disallowed CI/dev modules.
      • pip show package metadata checks for disallowed CI/dev packages.
    • Frontend-specific deep checks:
      • OS package metadata checks (apk/dpkg when available) for disallowed runtime leaks.
      • Directory-based checks for development package trees (node_modules, .venv, site-packages, dist-packages in sensitive paths).

Documentation updates

  • Updated docs/DEVELOPMENT.md:

    • Clarifies runtime-vs-validation enforcement and where checks run.
    • Notes purity checks include binaries and metadata artifacts.

  • Updated docs/CICD_MULTI_STAGE_BUILD.md:

    • Adds explicit “Runtime Boundary Enforcement” section.
    • Documents metadata-level purity probes.

  • Updated docs/DEPLOYABLE_RUNTIME_CONTRACT.md:

    • Replaces future-only language with current enforcement hooks.
    • Documents binary + metadata-level purity enforcement.

Acceptance Criteria Mapping

  1. Deployable backend/frontend image paths do not require CI-only tool installation

    • Enforced by:
      • scripts/check-dockerfile-boundaries.sh
      • scripts/verify-deployable-image-purity.sh
      • docker-build-main.yaml pre-publish gates

  2. Checks and tests execute in dedicated validation environment(s)

    • Reinforced by:
      • cicd-checks.yaml boundary-check job running in CICD validation image
      • Existing check/test workflow usage of CICD image

  3. Workflow docs identify runtime vs validation concerns

    • Addressed via updates to:
      • docs/DEVELOPMENT.md
      • docs/CICD_MULTI_STAGE_BUILD.md
      • docs/DEPLOYABLE_RUNTIME_CONTRACT.md

Scope / Non-Goals

  • Included:

    • Structural separation enforcement
    • Workflow-level guardrails
    • Documentation clarity and traceability

  • Not included:

    • Full staging deployment wiring
    • Security policy redesign

Notes for Reviewers

  • Main enforcement path is in docker-build-main.yaml before CICD image publish.
  • New scripts are intentionally fail-fast and policy-oriented.
  • Existing deployable Dockerfiles currently satisfy the new gates.
## Summary Implements issue #59 by enforcing a hard boundary between CI validation tooling and deployable runtime images. This PR: - Adds automated deployable-runtime boundary checks in CI. - Verifies deployable backend/frontend artifacts are free of CI/development tooling. - Documents runtime-vs-validation ownership and enforcement behavior. ## What Changed ### CI workflow enforcement - Updated `.gitea/workflows/docker-build-main.yaml` to: - Checkout additional verification inputs (`Dockerfile.backend`, `Dockerfile.frontend`, scripts, backend/frontend directories). - Run `scripts/check-dockerfile-boundaries.sh`. - Build deployable runtime images (`Dockerfile.backend`, `Dockerfile.frontend --target production`). - Run `scripts/verify-deployable-image-purity.sh` against both images before publishing CICD image. - Updated `.gitea/workflows/cicd-checks.yaml` to add: - `dockerfile-boundary-check` job. - Boundary validation execution inside the CICD validation image. ### New enforcement scripts - Added `scripts/check-dockerfile-boundaries.sh`: - Ensures deployable Dockerfiles do **not** reference CICD image paths (`cicd-base`, `CICD_BASE_IMAGE`, `Dockerfile.cicd*`, etc.). - Ensures deployable Dockerfiles do **not** include disallowed CI-only tooling tokens. - Enforces runtime base expectations: - Backend: `python:3.14-slim` - Frontend production target: `nginx:alpine` - Added `scripts/verify-deployable-image-purity.sh`: - Baseline binary checks for disallowed tooling. - Backend-specific deep checks: - Python module import probes for disallowed CI/dev modules. - `pip show` package metadata checks for disallowed CI/dev packages. - Frontend-specific deep checks: - OS package metadata checks (`apk`/`dpkg` when available) for disallowed runtime leaks. - Directory-based checks for development package trees (`node_modules`, `.venv`, `site-packages`, `dist-packages` in sensitive paths). ## Documentation updates - Updated `docs/DEVELOPMENT.md`: - Clarifies runtime-vs-validation enforcement and where checks run. - Notes purity checks include binaries and metadata artifacts. - Updated `docs/CICD_MULTI_STAGE_BUILD.md`: - Adds explicit “Runtime Boundary Enforcement” section. - Documents metadata-level purity probes. - Updated `docs/DEPLOYABLE_RUNTIME_CONTRACT.md`: - Replaces future-only language with current enforcement hooks. - Documents binary + metadata-level purity enforcement. ## Acceptance Criteria Mapping 1. **Deployable backend/frontend image paths do not require CI-only tool installation** - Enforced by: - `scripts/check-dockerfile-boundaries.sh` - `scripts/verify-deployable-image-purity.sh` - `docker-build-main.yaml` pre-publish gates 2. **Checks and tests execute in dedicated validation environment(s)** - Reinforced by: - `cicd-checks.yaml` boundary-check job running in CICD validation image - Existing check/test workflow usage of CICD image 3. **Workflow docs identify runtime vs validation concerns** - Addressed via updates to: - `docs/DEVELOPMENT.md` - `docs/CICD_MULTI_STAGE_BUILD.md` - `docs/DEPLOYABLE_RUNTIME_CONTRACT.md` ## Scope / Non-Goals - Included: - Structural separation enforcement - Workflow-level guardrails - Documentation clarity and traceability - Not included: - Full staging deployment wiring - Security policy redesign ## Notes for Reviewers - Main enforcement path is in `docker-build-main.yaml` before CICD image publish. - New scripts are intentionally fail-fast and policy-oriented. - Existing deployable Dockerfiles currently satisfy the new gates.
darkhelm added 1 commit 2026-06-19 19:03:43 -04:00
feat(ci): enforce runtime-validation image separation
Some checks failed
CICD Start / Sanity and Base Decision (pull_request) Failing after 10m34s
Details
bb526cde80 
Add Dockerfile boundary checks and deployable image purity validation for backend/frontend runtime artifacts. Wire enforcement into CI workflows and document runtime-vs-validation ownership.
darkhelm added 1 commit 2026-06-19 23:04:23 -04:00
chore: trigger cicd via empty commit
All checks were successful
CICD Start / Sanity and Base Decision (pull_request) Successful in 13s
Details
8d1a6fc2ae
All checks were successful
CICD Start / Sanity and Base Decision (pull_request) Successful in 13s
Details
This pull request can be merged automatically.
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin feature/issue-59-runtime-validation-separation:feature/issue-59-runtime-validation-separation
git checkout feature/issue-59-runtime-validation-separation
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
afk
Autonomous-friendly issue
 algorithm
Selection logic
 api
API contract
 backend
Backend related
 database
Database related
 devex
Developer experience
 docs
Documentation
 epic
Top-level planning item
 frontend
Frontend related
 hitl
Requires human-in-the-loop decision
 ingestion
Ingestion/sync
 ops
Operations
 performance
Performance
 realtime
Realtime/eventing
 release
Release readiness
 security
Security
 task
Implementation ticket
 testing
Testing
 ui
UI/UX
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
copilotcoder darkhelm renovate-bot repository-bot
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DarkHelm.org/plex-playlist#69
Delete Branch "feature/issue-59-runtime-validation-separation"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?