Files
familysync/.planning/quick/260613-dmw-exclude-gitea-workflow-config-changes-fr/260613-dmw-PLAN.md
T
Lucas Berger 9be3b7ba37
CI / changes (pull_request) Successful in 2s
CI / fast-checks (pull_request) Successful in 1m23s
CI / api (pull_request) Successful in 1m1s
CI / harness (pull_request) Successful in 3m51s
CI / security (pull_request) Successful in 39s
CI / gate (pull_request) Successful in 2s
docs(quick-260613-dmw): exclude .gitea/** from CI heavy-job paths-filter
2026-06-13 09:53:25 -04:00

6.0 KiB

phase, plan, type, wave, depends_on, files_modified, autonomous, requirements, must_haves
phase plan type wave depends_on files_modified autonomous requirements must_haves
quick-260613-dmw 01 execute 1
.gitea/workflows/ci.yml
true
truths artifacts key_links
A PR touching ONLY files under .gitea/** resolves code=false (heavy api/harness jobs skip, gate treats them as OK)
A PR touching .gitea/** AND app code/lockfile still resolves code=true (heavy jobs run)
ci.yml remains valid YAML and passes pnpm format:check
path provides contains
.gitea/workflows/ci.yml changes-job paths-filter with .gitea/** excluded from the code filter !.gitea/**
from to via pattern
.gitea/workflows/ci.yml changes.code filter api/harness job if: needs.changes.outputs.code == 'true' negation pattern ordered after positive yml/yaml globs !.gitea/**
Exclude workflow-config changes (`.gitea/**`) from the CI `code` paths-filter so a PR that touches ONLY workflow/CI files is treated like a docs-only PR: the heavy `api` and `harness` jobs skip, while `fast-checks` (always runs; its `format:check` validates the workflow YAML) and `gate` still gate the PR.

Purpose: Workflow-only edits should not pay the multi-minute MariaDB + integration + Playwright harness cost. Per the project's tiered-gate rule, a CI-config edit does not need the full test harness — fast-checks + gate are sufficient gates for it.

Output: A one-line addition to the changes job's dorny/paths-filter@v4 code filter in .gitea/workflows/ci.yml.

<execution_context> @$HOME/.claude/gsd-core/workflows/execute-plan.md @$HOME/.claude/gsd-core/templates/summary.md </execution_context>

@.planning/STATE.md @.gitea/workflows/ci.yml Task 1: Exclude .gitea/** from the CI code paths-filter .gitea/workflows/ci.yml In the `changes` job's `dorny/paths-filter@v4` step (`id: filter`), add a single negation entry `- '!.gitea/**'` to the `code` filter list. Place it as the LAST entry of the `code` list — after every positive glob (`**/*.yaml`, `**/*.yml`, `apps/**`, `packages/**`, `pnpm-lock.yaml`, `Dockerfile`, `docker-compose*.yml`). Ordering is load-bearing: dorny/paths-filter evaluates patterns in sequence and a negation only overrides positive globs that precede it; the `**/*.yml`/`**/*.yaml` globs that currently make `.gitea/` workflow edits resolve `code=true` MUST appear before the negation.

Match the existing two-space list indentation and single-quoted-glob style used by the surrounding entries. Do NOT remove or reorder any existing positive glob. Do NOT touch the fast-checks, api, harness, security, or gate jobs, the outputs.code mapping, or which jobs gate aggregates in its needs. This negation is the only change to the file.

Net behavior after the edit:

  • PR touching ONLY .gitea/** (e.g. editing this workflow): the yml/yaml positive match is overridden by the negation → code=falseapi/harness carry their if: ... code == 'true' and skip → gate's success-or-skipped loop accepts them.
  • PR touching .gitea/** AND app code or lockfile (e.g. apps/**, pnpm-lock.yaml): the app-code positive glob still matches and is not under .gitea/, so the negation does not cancel it → code=true → heavy jobs run. cd /home/luc/Projects/familysync && awk '/^ fast-checks:/{exit} /code:/{f=1} f' .gitea/workflows/ci.yml | grep -nE "'!.gitea/**'|'**/*.ya?ml'" && python3 -c 'import sys,yaml; d=yaml.safe_load(open(".gitea/workflows/ci.yml")); code=d["jobs"]["changes"]["steps"][0]["with"]["filters"]; lines=[l.strip().lstrip("- ").strip("\x27"") for l in code.splitlines() if l.strip().startswith("- ")]; neg=lines.index("!.gitea/"); yml=max(i for i,p in enumerate(lines) if p in ("/.yml","**/.yaml")); assert neg>yml, f"negation at {neg} must follow last yml/yaml glob at {yml}"; print("OK: .gitea/** negation present and ordered after yml/yaml globs")' .gitea/workflows/ci.yml parses as valid YAML; the code filter contains !.gitea/** positioned after the **/*.yml/**/*.yaml globs; no positive glob removed; only the changes job changed; pnpm format:check passes for the file.
1. YAML validity: `python3 -c 'import yaml; yaml.safe_load(open(".gitea/workflows/ci.yml"))'` exits 0. 2. Negation present and correctly ordered: the `code` list contains `!.gitea/**` as an entry that appears AFTER both `**/*.yml` and `**/*.yaml` (asserted by the Task 1 automated check). 3. Formatting: `pnpm format:check` passes (no Prettier diff on the workflow file). 4. Scope guard: `git diff --stat` shows ONLY `.gitea/workflows/ci.yml` changed, and `git diff .gitea/workflows/ci.yml` shows a single added line `- '!.gitea/**'` (no deletions, no other-job edits).

<success_criteria>

  • A workflow-only PR (touching only .gitea/**) resolves code=falseapi + harness skip → gate passes via its success-or-skipped acceptance.
  • A PR touching .gitea/** plus app code/lockfile resolves code=true → heavy jobs run.
  • fast-checks and gate are unchanged and still gate every PR; fast-checks format:check continues to validate workflow YAML.
  • No existing positive glob removed; no change to fast-checks, api, harness, security, or gate. </success_criteria>
Create `.planning/quick/260613-dmw-exclude-gitea-workflow-config-changes-fr/260613-dmw-SUMMARY.md` when done.

Suggested commit message: ci: exclude .gitea/** from heavy-job paths-filter

Body rationale: Workflow-only edits shouldn't pay for the multi-minute MariaDB/integration/harness suite. A negation - '!.gitea/**' (ordered after the yml/yaml globs) makes CI-config-only PRs resolve code=false so api/harness skip like docs; fast-checks (format:check still validates the workflow YAML) + gate continue to gate them. PRs that also touch app code/lockfile still resolve code=true and run the full suite.