4 Commits

Author	SHA1	Message	Date
copilotcoder	a2d7013dd4	chore: tune runner defaults and pin renovate to 8gb	2026-07-14 10:12:57 -04:00
Xlorep DarkHelm	f3698b095b	Stabilize self-hosted CI workflows and resolve issue #62 (#73) ... ## Summary Hardens CI workflows for self-hosted Gitea runners by stabilizing E2E execution and Renovate behavior across internal/external network paths. Closes #62 ## What Changed ### E2E workflow reliability - Fixed E2E workspace handoff to ensure expected repository contents are present during test execution. - Added stricter preflight checks for required frontend files before running E2E. - Reduced mount/path fragility while preserving runtime image pull and compose flow. ### Renovate workflow hardening - Added internal-first endpoint reachability selection with fallback handling. - Added token preflight checks for repository access. - Added explicit host-rule auth handling for API/git paths. - Added container-level connectivity preflight diagnostics. - Added git URL override aligned with selected endpoint context. - Removed incorrect forced Dogar host-IP pinning that broke HTTPS clone routing. ## Why CI behavior was sensitive to runner networking and Renovate clone/auth interactions. These changes make the workflow deterministic in our runner topology and address recurring CI failures. ## Scope - Workflow logic only (`cicd.yaml`, `renovate.yml`) - No app feature or API behavior changes ## Validation - Workflow YAML validation passed during updates. - Changes were applied and verified iteratively from real failing run diagnostics. Co-authored-by: copilotcoder <copilotcoder@darkhelm.org> Reviewed-on: #73	2026-07-13 11:16:16 -04:00
Xlorep DarkHelm	1f6cafa1bc	TASK: Replace integration lane with post-build backend runtime black-box tests (#72) ... ## Summary Replace the existing source-context integration lane with backend runtime black-box integration checks that run against started deployable containers. This change wires deployable backend image references (both commit tag and immutable digest) from the build workflow into the tests workflow, then validates runtime behavior over network endpoints. ## Why Integration confidence should come from testing running service artifacts, not only source-mounted or in-process execution. ## What Changed - Build workflow now: - Publishes deployable backend image tag reference and digest reference - Exposes both as job outputs - Passes both references into CICD Tests dispatch inputs - CICD Tests workflow now: - Accepts deployable backend tag and digest inputs - Propagates these through setup outputs - Replaces previous integration lane behavior with runtime black-box execution: - Starts isolated Docker network - Starts Postgres container - Starts backend container from digest-pinned deployable image - Enforces tag-to-digest consistency before running checks - Runs endpoint checks against live container: - GET / - GET /compatibility - GET /health - Captures backend/db logs and container state on failure - Cleans up containers and network via trap - Documentation updated: - Runtime contract enforcement section now includes runtime black-box integration checks - CI success summary now reflects runtime integration lane behavior ## Scope Included: - Backend runtime black-box integration replacement for the existing integration lane - Digest + tag identity enforcement - Failure diagnostics for triage Out of scope: - Frontend runtime smoke checks - E2E lane redesign ## Acceptance Criteria Mapping - Integration tests execute against runtime container endpoints: ✅ - Integration lane consumes built image references (not source-mounted execution): ✅ - Failures surface service logs and test logs for triage: ✅ ## Verification - Workflow files pass local validation checks - Pre-commit hooks pass on committed changes - Branch pushed and ready for PR review ## Related - Issue: #61 - Dependency context: #66 Co-authored-by: copilotcoder <copilotcoder@darkhelm.org> Reviewed-on: #72	2026-07-05 22:48:57 -04:00
Cliff Hill	d02039a22e	Backend runtime upgraded to Python 3.14 with exact dependency pinning (#57) ... Signed-off-by: Cliff Hill <xlorep@darkhelm.org> ## Summary Upgrades backend runtime baseline and dependency management for issue #10. ### Changes 1. **Python Baseline**: Updated from 3.13 to 3.14 - Updated `backend/pyproject.toml` requires-python constraint - Updated `backend/pyrightconfig.json` pythonVersion - Updated all Dockerfile and CI references 2. **Dependency Pinning**: Switched to exact version pins in `backend/pyproject.toml` - All dev and runtime dependencies now use `==` instead of `>=` - `fastapi==0.120.2`, `uvicorn==0.38.0` - ruff, pyright, pytest suite pinned to current resolved versions - Regenerated `backend/uv.lock` under Python 3.14 3. **Startup Compatibility Guard** (TDD via RED→GREEN) - New `compatibility_status()` function evaluates runtime and pinned deps - Startup raises `RuntimeError` if policy fails - Implemented via FastAPI lifespan (non-deprecated) handler 4. **Compatibility Status Endpoint** - New `GET /compatibility` returns policy status, runtime version, and package checks - Shares single source of truth with startup validation 5. **Integration Tests** - Added failing-then-passing tests for startup guard and endpoint behavior - 100% coverage maintained 6. **Direnv Configuration** - Added `UV_PYTHON="3.14"` pin to repo `.envrc` - Ensures direnv creates/recreates venv with correct Python version ### Validation - ✅ ruff format/check - ✅ pyright strict (0 errors) - ✅ pytest: 8 passed, 100% coverage (>=95 gate) - ✅ pydoclint: pass - ✅ xdoctest: pass ### Notes - SQLAlchemy/SQLModel introduction deferred to next pass per scope - Compatibility logic currently validates fastapi/uvicorn pins (runtime deps) - Ready for container build validation and Renovate bot testing Co-authored-by: copilotcoder <copilotcoder@darkhelm.org> Reviewed-on: #57 Co-authored-by: Cliff Hill <xlorep@darkhelm.org> Co-committed-by: Cliff Hill <xlorep@darkhelm.org>	2026-06-18 11:19:24 -04:00