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

TASK: Split CI tooling environment from deployable runtime images #59

New Issue
Open
opened 2026-06-17 19:29:44 -04:00 by darkhelm · 1 comment
darkhelm commented 2026-06-17 19:29:44 -04:00
Owner
Copy Link

Summary

Introduce or refactor CI validation environments so lint, typecheck, test, and browser tooling are separated from deployable runtime images.

Problem

Deployable artifacts should not carry CI-only dependencies. Validation environments should own test and check tooling.

Scope

  1. Identify CI-only tools currently relied on during checks/tests.
  2. Define the dedicated validation environment image(s) and ownership.
  3. Refactor workflow usage to consume validation environment(s) for checks/tests.
  4. Keep deployable runtime image build path independent from CI tooling layers.

Out of Scope

  1. Full staging deployment wiring.
  2. Security policy redesign.

Acceptance Criteria

  1. Deployable backend/frontend image paths do not require CI-only tool installation.
  2. Checks and tests execute in dedicated validation environment(s).
  3. Workflow docs identify where runtime vs validation concerns live.

Dependencies

Issue: Define and lock minimal deployable backend/frontend image requirements.

Definition of Done

Validation tooling and runtime artifacts are structurally separated in build and workflow paths.

## Summary Introduce or refactor CI validation environments so lint, typecheck, test, and browser tooling are separated from deployable runtime images. ## Problem Deployable artifacts should not carry CI-only dependencies. Validation environments should own test and check tooling. ## Scope 1. Identify CI-only tools currently relied on during checks/tests. 2. Define the dedicated validation environment image(s) and ownership. 3. Refactor workflow usage to consume validation environment(s) for checks/tests. 4. Keep deployable runtime image build path independent from CI tooling layers. ## Out of Scope 1. Full staging deployment wiring. 2. Security policy redesign. ## Acceptance Criteria 1. Deployable backend/frontend image paths do not require CI-only tool installation. 2. Checks and tests execute in dedicated validation environment(s). 3. Workflow docs identify where runtime vs validation concerns live. ## Dependencies Issue: Define and lock minimal deployable backend/frontend image requirements. ## Definition of Done Validation tooling and runtime artifacts are structurally separated in build and workflow paths.
darkhelm changed title from Split CI tooling environment from deployable runtime images to TASK: Split CI tooling environment from deployable runtime images 2026-06-18 11:56:08 -04:00
darkhelm added the ops label 2026-06-18 11:57:38 -04:00
darkhelm added this to the E10 - Separate deployable runtime images from CI milestone 2026-06-18 11:58:23 -04:00
darkhelm added this to the Main Project Board project 2026-06-18 11:59:14 -04:00
copilotcoder was assigned by darkhelm 2026-06-18 11:59:46 -04:00
darkhelm added the afkdevextask labels 2026-06-18 12:03:33 -04:00
darkhelm moved this to To Do in Main Project Board on 2026-06-19 09:23:50 -04:00
darkhelm moved this to In Progress in Main Project Board on 2026-06-19 17:02:32 -04:00
darkhelm commented 2026-06-19 17:07:36 -04:00
Author
Owner
Copy Link

Plan: Split CI Tooling from Deployable Runtime Images

Summary

This plan delivers issue #59 by making validation tooling ownership explicit in CI image/workflow paths while keeping deployable backend/frontend runtime paths independent from CI-only tooling layers.

Plan Of Action

  1. Phase 1: Baseline and boundary mapping

  2. Build a tooling inventory from Dockerfile.cicd-base, Dockerfile.cicd, Dockerfile.backend, Dockerfile.frontend, cicd-checks workflow, and cicd-tests workflow.

  3. Classify each tool as runtime-required vs validation-only using runtime contract and ADR003.

  4. Record current coupling points where workflows rely on implicit tool availability instead of explicit validation-environment ownership.

  5. Phase 2: Validation environment ownership refactor

  6. Update CI image layering in Dockerfile.cicd-base and Dockerfile.cicd so lint/typecheck/test tooling is clearly owned by validation image paths.

  7. Update workflows to run checks/tests in dedicated validation environment(s), with explicit job-level usage in cicd-checks workflow and cicd-tests workflow.

  8. Preserve deployable image path independence in Dockerfile.backend and Dockerfile.frontend, avoiding CI-only installation requirements there.

  9. Phase 3: Enforcement and regression guards

  10. Add CI guards (scripts + workflow hooks) to fail on CI-only tooling leakage into deployable artifacts; wire into docker-build-main workflow.

  11. Add Dockerfile/workflow boundary checks under scripts so future changes cannot silently re-couple runtime and validation concerns.

  12. Keep checks scoped to issue requirements (no staging wiring or security-policy redesign).

  13. Phase 4: Documentation and handoff

  14. Update boundary ownership documentation in CICD multi-stage doc and development doc.

  15. Cross-link runtime constraints from runtime contract and decision rationale from ADR003.

  16. Add reviewer checklist describing where runtime concerns live vs where validation concerns live.

Verification Plan

  1. Validation jobs proof

  2. Confirm lint, typecheck, and tests run in dedicated validation environment(s) via updated CI workflows.

  3. Confirm workflow logs show validation image/tooling usage and not deployable runtime paths.

  4. Deployable runtime purity proof

  5. Build backend/frontend deployable images from Dockerfile.backend and Dockerfile.frontend.

  6. Verify deployable build paths do not require CI-only tool installation and remain runtime-focused.

  7. Documentation proof

  8. Verify docs explicitly identify runtime-vs-validation ownership and link to the controlling files/workflows.

Acceptance Criteria Mapping

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

  2. Satisfied by preserving/guarding runtime-only paths in Dockerfile.backend and Dockerfile.frontend, plus CI leakage checks in workflows/scripts.

  3. Checks/tests execute in dedicated validation environment(s)

  4. Satisfied by explicit validation image usage in cicd-checks workflow and cicd-tests workflow.

  5. Workflow docs identify runtime vs validation concerns

  6. Satisfied by updates in CICD multi-stage doc, development doc, and references to runtime contract.

Scope Boundaries

  1. Included

  2. CI/runtime structural separation, workflow consumption changes, enforcement checks, and docs updates tied to issue #59.

  3. Excluded

  4. Full staging deployment wiring.

  5. Security policy redesign.

## Plan: Split CI Tooling from Deployable Runtime Images ### Summary This plan delivers issue #59 by making validation tooling ownership explicit in CI image/workflow paths while keeping deployable backend/frontend runtime paths independent from CI-only tooling layers. ### Plan Of Action 1. Phase 1: Baseline and boundary mapping 2. Build a tooling inventory from [Dockerfile.cicd-base](Dockerfile.cicd-base), [Dockerfile.cicd](Dockerfile.cicd), [Dockerfile.backend](Dockerfile.backend), [Dockerfile.frontend](Dockerfile.frontend), [cicd-checks workflow](.gitea/workflows/cicd-checks.yaml), and [cicd-tests workflow](.gitea/workflows/cicd-tests.yaml). 3. Classify each tool as runtime-required vs validation-only using [runtime contract](docs/DEPLOYABLE_RUNTIME_CONTRACT.md) and [ADR003](docs/adr/ADR003-deployable_runtime_image_contract.md). 4. Record current coupling points where workflows rely on implicit tool availability instead of explicit validation-environment ownership. 5. Phase 2: Validation environment ownership refactor 6. Update CI image layering in [Dockerfile.cicd-base](Dockerfile.cicd-base) and [Dockerfile.cicd](Dockerfile.cicd) so lint/typecheck/test tooling is clearly owned by validation image paths. 7. Update workflows to run checks/tests in dedicated validation environment(s), with explicit job-level usage in [cicd-checks workflow](.gitea/workflows/cicd-checks.yaml) and [cicd-tests workflow](.gitea/workflows/cicd-tests.yaml). 8. Preserve deployable image path independence in [Dockerfile.backend](Dockerfile.backend) and [Dockerfile.frontend](Dockerfile.frontend), avoiding CI-only installation requirements there. 9. Phase 3: Enforcement and regression guards 10. Add CI guards (scripts + workflow hooks) to fail on CI-only tooling leakage into deployable artifacts; wire into [docker-build-main workflow](.gitea/workflows/docker-build-main.yaml). 11. Add Dockerfile/workflow boundary checks under [scripts](scripts) so future changes cannot silently re-couple runtime and validation concerns. 12. Keep checks scoped to issue requirements (no staging wiring or security-policy redesign). 13. Phase 4: Documentation and handoff 14. Update boundary ownership documentation in [CICD multi-stage doc](docs/CICD_MULTI_STAGE_BUILD.md) and [development doc](docs/DEVELOPMENT.md). 15. Cross-link runtime constraints from [runtime contract](docs/DEPLOYABLE_RUNTIME_CONTRACT.md) and decision rationale from [ADR003](docs/adr/ADR003-deployable_runtime_image_contract.md). 16. Add reviewer checklist describing where runtime concerns live vs where validation concerns live. ### Verification Plan 1. Validation jobs proof 2. Confirm lint, typecheck, and tests run in dedicated validation environment(s) via updated CI workflows. 3. Confirm workflow logs show validation image/tooling usage and not deployable runtime paths. 4. Deployable runtime purity proof 5. Build backend/frontend deployable images from [Dockerfile.backend](Dockerfile.backend) and [Dockerfile.frontend](Dockerfile.frontend). 6. Verify deployable build paths do not require CI-only tool installation and remain runtime-focused. 7. Documentation proof 8. Verify docs explicitly identify runtime-vs-validation ownership and link to the controlling files/workflows. ### Acceptance Criteria Mapping 1. Deployable backend/frontend image paths do not require CI-only tooling installation 2. Satisfied by preserving/guarding runtime-only paths in [Dockerfile.backend](Dockerfile.backend) and [Dockerfile.frontend](Dockerfile.frontend), plus CI leakage checks in workflows/scripts. 3. Checks/tests execute in dedicated validation environment(s) 4. Satisfied by explicit validation image usage in [cicd-checks workflow](.gitea/workflows/cicd-checks.yaml) and [cicd-tests workflow](.gitea/workflows/cicd-tests.yaml). 5. Workflow docs identify runtime vs validation concerns 6. Satisfied by updates in [CICD multi-stage doc](docs/CICD_MULTI_STAGE_BUILD.md), [development doc](docs/DEVELOPMENT.md), and references to [runtime contract](docs/DEPLOYABLE_RUNTIME_CONTRACT.md). ### Scope Boundaries 1. Included 2. CI/runtime structural separation, workflow consumption changes, enforcement checks, and docs updates tied to issue #59. 3. Excluded 4. Full staging deployment wiring. 5. Security policy redesign.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
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 afk devex ops task
Milestone
No items
No Milestone E10 - Separate deployable runtime images from CI
Projects
Clear projects
No project Main Project Board
Assignees
Clear assignees
copilotcoder darkhelm renovate-bot repository-bot
No Assignees copilotcoder
1 Participants
Notifications
Due Date
No due date set.
Blocks
#66 EPIC: Separate deployable runtime images from CI validation environments
DarkHelm.org/plex-playlist
Reference: DarkHelm.org/plex-playlist#59
Delete Branch "%!s()"

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?