fix(ci): move ci.yml to .forgejo/workflows to trigger pull_request #10

New issue

Closed

opened 2026-08-07 15:57:47 +03:00 by slaid098 · 0 comments

slaid098 commented

2026-08-07 15:57:47 +03:00

Owner

Контекст

В PR #6 deploy.yml перенесён из .github/workflows/ в .forgejo/workflows/ (Forgejo-native каталог). При этом ci.yml остался в .github/workflows/ci.yml. После этого CI перестал триггериться на pull_request:

PR #5 (до переноса) — ci.yml запустился на pull_request (run id=98, event=pull_request, success).
PR #6 (перенос deploy.yml) — ci.yml НЕ запустился на pull_request.
PR #9 (feat/subscriptions, не трогает workflows) — ci.yml НЕ запустился на pull_request.
POST /actions/workflows/ci.yml/dispatches → 404 «workflow not found» — Forgejo не видит ci.yml как зарегистрированный workflow.

Гипотеза: Forgejo перестал сканировать .github/workflows/ после появления .forgejo/workflows/ (либо не поддерживает смешанный режим, либо требуется явная конфигурация). deploy.yml в .forgejo/workflows/ работает (runs 106-119), ci.yml в .github/workflows/ — нет.

Задача

Перенести ci.yml из .github/workflows/ci.yml в .forgejo/workflows/ci.yml (git mv).
Удалить пустой .github/workflows/ каталог (если больше нет файлов).
Проверить что .github/ каталог пуст — удалить если да (зависимости от него нет, см. «Влияние»).
После переноса — открыть тест-PR или workflow_dispatch для проверки триггера pull_request.
Если .github/workflows/ всё же поддерживается Forgejo (конфиг/дока) — альтернатива: оставить ci.yml в .github/ и найти причину 404 на dispatch (возможно workflow надо «активировать» в web UI Forgejo: Actions → Enable). В этом случае — записать в memory процедуру активации.

Контракты

ci.yml триггерится на pull_request (branches: [main]) и push (branches: [main]) — как раньше.
deploy.yml не трогается (работает в .forgejo/workflows/).
Логика ci.yml (checkout → setup-node → npm ci → lint → typecheck → knip → test → build) не меняется.
runs-on: ubuntu-latest, node-version: "22", cache: "npm" — сохраняются.

Инварианты

Quality-gate (lint + typecheck + knip + test + build) остаётся обязательным на PR.
npm run build в CI — единственный детектор клиент/серверных границ (node:fs в клиентском компоненте, hydration mismatches). Локальные lint/typecheck/test/knip НЕ ловят. Без CI-билда такие баги проходят.
pipeline-status oracle использует presence CI checks для вердикта. Без CI — AMBIGUOUS, merge по review APPROVE без quality-gate.

Граничные случаи

После переноса ci.yml — первый pull_request может не триггериться если workflow-файл «новый» (Forgejo может требовать explicit enable в UI для новых workflow-файлов). Проверить и задокументировать.
push на main (после merge PR) — должен триггерить и ci.yml (quality), и deploy.yml (deploy). Проверить порядок (ci → deploy или параллельно).
Если .github/ остался с другими файлами (dependabot.yml удалён в PR #6 — проверить) — не удалять каталог, только workflows/.

Влияние на связанные компоненты

.forgejo/workflows/deploy.yml — НЕ трогается.
pipeline-status oracle — после фикса перестанет возвращать AMBIGUOUS на PR (CI checks будут presence).
run-pipeline skill — после фикса CI-фаза будет детерминированной (ждать CI checks). Сейчас fallback: merge по review APPROVE без CI.
project-status oracle (infra check) — проверяет ci.yml наличие; путь в чеке обновить если хардкод .github/workflows/.
Memory slaid098-dev-002.md — запись про «ci.yml в .github/ не триггерится» (добавить после фикса).

Вне scope

Миграция ci.yml логики (lint/typecheck/knip/test/build) — не меняется.
Разделение ci.yml на несколько jobs (lint, test, build — параллельно) — будущий enhancement.
Сам хост Forgejo (версия 16.0.2) — не обновляется.
Контент PR #9 (subscriptions) — вливается отдельно по review APPROVE (локальные проверки зелёные).

Критерии приемки

ci.yml перенесён в .forgejo/workflows/ci.yml (или активирован в UI если .github/ поддерживается).
Новый PR (любой) триггерит ci.yml на pull_request — run виден в /actions/runs, event=pull_request, status=success (или expected failure если код-баг).
POST /actions/workflows/ci.yml/dispatches → 204 (workflow найден).
pipeline-status на новом PR → CI ✅ (не AMBIGUOUS).
.github/ каталог пуст или удалён (если нет других файлов).
PR с переносом проходит сам quality-gate (chicken-and-egg: если CI не работает — мержить по review APPROVE, после merge push-триггер проверит).

## Контекст В PR #6 deploy.yml перенесён из `.github/workflows/` в `.forgejo/workflows/` (Forgejo-native каталог). При этом `ci.yml` остался в `.github/workflows/ci.yml`. После этого CI перестал триггериться на `pull_request`: - PR #5 (до переноса) — ci.yml запустился на pull_request (run id=98, event=pull_request, success). - PR #6 (перенос deploy.yml) — ci.yml НЕ запустился на pull_request. - PR #9 (feat/subscriptions, не трогает workflows) — ci.yml НЕ запустился на pull_request. - `POST /actions/workflows/ci.yml/dispatches` → 404 «workflow not found» — Forgejo не видит `ci.yml` как зарегистрированный workflow. Гипотеза: Forgejo перестал сканировать `.github/workflows/` после появления `.forgejo/workflows/` (либо не поддерживает смешанный режим, либо требуется явная конфигурация). `deploy.yml` в `.forgejo/workflows/` работает (runs 106-119), `ci.yml` в `.github/workflows/` — нет. ## Задача 1. Перенести `ci.yml` из `.github/workflows/ci.yml` в `.forgejo/workflows/ci.yml` (`git mv`). 2. Удалить пустой `.github/workflows/` каталог (если больше нет файлов). 3. Проверить что `.github/` каталог пуст — удалить если да (зависимости от него нет, см. «Влияние»). 4. После переноса — открыть тест-PR или workflow_dispatch для проверки триггера `pull_request`. 5. Если `.github/workflows/` всё же поддерживается Forgejo (конфиг/дока) — альтернатива: оставить `ci.yml` в `.github/` и найти причину 404 на dispatch (возможно workflow надо «активировать» в web UI Forgejo: Actions → Enable). В этом случае — записать в memory процедуру активации. ## Контракты - `ci.yml` триггерится на `pull_request` (branches: [main]) и `push` (branches: [main]) — как раньше. - `deploy.yml` не трогается (работает в `.forgejo/workflows/`). - Логика ci.yml (checkout → setup-node → npm ci → lint → typecheck → knip → test → build) не меняется. - `runs-on: ubuntu-latest`, `node-version: "22"`, `cache: "npm"` — сохраняются. ## Инварианты - Quality-gate (lint + typecheck + knip + test + build) остаётся обязательным на PR. - `npm run build` в CI — единственный детектор клиент/серверных границ (node:fs в клиентском компоненте, hydration mismatches). Локальные lint/typecheck/test/knip НЕ ловят. Без CI-билда такие баги проходят. - `pipeline-status` oracle использует presence CI checks для вердикта. Без CI — AMBIGUOUS, merge по review APPROVE без quality-gate. ## Граничные случаи - После переноса ci.yml — первый pull_request может не триггериться если workflow-файл «новый» (Forgejo может требовать explicit enable в UI для новых workflow-файлов). Проверить и задокументировать. - `push` на main (после merge PR) — должен триггерить и ci.yml (quality), и deploy.yml (deploy). Проверить порядок (ci → deploy или параллельно). - Если `.github/` остался с другими файлами (dependabot.yml удалён в PR #6 — проверить) — не удалять каталог, только `workflows/`. ## Влияние на связанные компоненты - `.forgejo/workflows/deploy.yml` — НЕ трогается. - `pipeline-status` oracle — после фикса перестанет возвращать AMBIGUOUS на PR (CI checks будут presence). - `run-pipeline` skill — после фикса CI-фаза будет детерминированной (ждать CI checks). Сейчас fallback: merge по review APPROVE без CI. - `project-status` oracle (infra check) — проверяет `ci.yml` наличие; путь в чеке обновить если хардкод `.github/workflows/`. - Memory `slaid098-dev-002.md` — запись про «ci.yml в `.github/` не триггерится» (добавить после фикса). ## Вне scope - Миграция ci.yml логики (lint/typecheck/knip/test/build) — не меняется. - Разделение ci.yml на несколько jobs (lint, test, build — параллельно) — будущий enhancement. - Сам хост Forgejo (версия 16.0.2) — не обновляется. - Контент PR #9 (subscriptions) — вливается отдельно по review APPROVE (локальные проверки зелёные). ## Критерии приемки - `ci.yml` перенесён в `.forgejo/workflows/ci.yml` (или активирован в UI если `.github/` поддерживается). - Новый PR (любой) триггерит ci.yml на `pull_request` — run виден в `/actions/runs`, event=pull_request, status=success (или expected failure если код-баг). - `POST /actions/workflows/ci.yml/dispatches` → 204 (workflow найден). - `pipeline-status` на новом PR → CI ✅ (не AMBIGUOUS). - `.github/` каталог пуст или удалён (если нет других файлов). - PR с переносом проходит сам quality-gate (chicken-and-egg: если CI не работает — мержить по review APPROVE, после merge push-триггер проверит).

slaid098 referenced this issue

2026-08-07 16:07:13 +03:00

refactor(header): unified menu navigation for all devices #11

slaid098 referenced this issue

2026-08-07 16:08:41 +03:00

refactor(header): unified menu navigation for all devices #11

slaid098 referenced this issue from a commit

2026-08-07 17:38:30 +03:00

fix(ci): move ci.yml to .forgejo/workflows to trigger pull_request

slaid098 referenced this issue from a pull request that will close it,

2026-08-07 17:38:36 +03:00

fix(ci): move ci.yml to .forgejo/workflows to trigger pull_request #12