From ad01ae92d4654ba575830fb71fa13caa117ba411 Mon Sep 17 00:00:00 2001 From: Ku6epXBOCTuK Date: Sat, 26 Sep 2026 15:04:05 +0500 Subject: [PATCH] ci: update docs, verify on push --- .github/workflows/quality.yml | 3 +++ AGENTS.md | 11 +++++----- docs/agent-workflow.md | 6 +++--- docs/plan-codebase-quality.md | 20 +++++++++++++++++- docs/quality-gates.md | 39 +++++++++++++++++++---------------- 5 files changed, 51 insertions(+), 28 deletions(-) diff --git a/.github/workflows/quality.yml b/.github/workflows/quality.yml index 9604402..02f3d5a 100644 --- a/.github/workflows/quality.yml +++ b/.github/workflows/quality.yml @@ -1,6 +1,9 @@ name: Quality on: + push: + branches: + - main pull_request: workflow_dispatch: diff --git a/AGENTS.md b/AGENTS.md index 715ee53..89a9a38 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -18,12 +18,11 @@ (docs) + `pnpm --dir web exec prettier --check .` (код). - Полный быстрый gate: `pnpm verify`; подробная матрица команд и CI — `docs/quality-gates.md`. -- После пуша результат CI проверяется явно: смотреть и blocking `verify`, и - non-blocking `e2e` — если тот job вообще запускался. `Quality` workflow живёт - на `pull_request` и `workflow_dispatch`, поэтому при прямом пуше в `main` - выполняется только `Deploy to GitHub Pages` со своим `verify`, а browser - matrix проверяется на PR или ручным запуском. Красный `e2e` не блокирует PR, - но остаётся падением — сообщать его фактический статус. +- После пуша результат CI проверяется явно: смотреть статусы отдельных job, а не + общий conclusion прогона. У `e2e` стоит `continue-on-error`, поэтому прогон с + упавшим e2e помечается как `success`. `Quality` workflow запускается на каждом + пуше в `main` и на `pull_request`, поэтому browser matrix проверяется сама; + ручной запуск нужен только для старого коммита. - Линтинг: `pnpm --dir web lint` (ESLint). Полный прогон дизайн-проверок: `pnpm --dir web lint:all` (ESLint + stylelint + токен-аудит). Каждый шаг выполняется, даже если предыдущий упал. Новые изменения не должны добавлять diff --git a/docs/agent-workflow.md b/docs/agent-workflow.md index 5d13b8b..bfe790a 100644 --- a/docs/agent-workflow.md +++ b/docs/agent-workflow.md @@ -123,8 +123,8 @@ E2E запускается отдельно от быстрых проверок Коммит и пуш делает разработчик. После пуша агент проверяет результат CI и сообщает его вместе с локальными проверками, включая случай, когда нужный job не -запускался: `Quality` workflow с browser matrix живёт на `pull_request` и -`workflow_dispatch`, поэтому прямой пуш в `main` проверяет только быстрый gate. -Процедура описана в `docs/quality-gates.md`. +запускался: статусы смотрятся по отдельным job, потому что общий conclusion +прогона с `continue-on-error` у `e2e` остаётся зелёным. Процедура описана в +`docs/quality-gates.md`. Следующий шаг начинается только после ревью текущего изменения. diff --git a/docs/plan-codebase-quality.md b/docs/plan-codebase-quality.md index ea9e1ec..cb9a44d 100644 --- a/docs/plan-codebase-quality.md +++ b/docs/plan-codebase-quality.md @@ -112,7 +112,8 @@ pnpm --dir web test:e2e - Добавить отдельный workflow для pull request: typecheck, unit, rule-тесты, lint, format и build. - E2E сначала запускать отдельным job; сделать его blocking после закрытия - известных ошибок и стабилизации baseline. + известных ошибок и стабилизации baseline. Решение отложено: условия matrix + пересматриваются после Q6f.3, см. раздел 7 «Отложенное решение». **Готово, когда:** одна команда воспроизводит все быстрые проверки, а deploy не может пройти при type/unit/lint/build-ошибке. @@ -498,3 +499,20 @@ refactor, новые i18n-правила и исправление продук - Какие unused design tokens можно удалить, а какие должны остаться? - Какие browser/e2e проверки должны быть обязательными для PR, а какие — отдельным ночным прогоном? + +### Отложенное решение: условия matrix и blocking e2e + +Окончательное решение про `e2e` в CI принимается **не сейчас**, а после +пересмотра условий тестов. К этому моменту нужно вернуться и решить одним шагом: + +1. Пересмотреть условия matrix: какие спецификации обязаны идти в + `browserContractTests` и `mobileTests`, нужен ли `png-fixtures` вне Chromium + и что делать с engine-специфичными расхождениями декодеров. +2. Накопить стабильные прогоны `e2e` на раннере (сейчас ориентир — 276 тестов, + ~3 мин на job) без падений по таймингу. +3. Только после этого решать, делать ли `e2e` blocking, и если да — снимать + `continue-on-error`, иначе общий conclusion прогона останется зелёным при + красном `e2e` (проверено на run `36225579363`). + +До этого решения `e2e` остаётся non-blocking baseline, а его фактический статус +проверяется по отдельному job, а не по conclusion прогона. diff --git a/docs/quality-gates.md b/docs/quality-gates.md index 5b5c3e8..644ef6a 100644 --- a/docs/quality-gates.md +++ b/docs/quality-gates.md @@ -83,14 +83,17 @@ per-project лимит воркеров, а browser matrix упирается в ### Что и когда запускается -| Workflow | Триггер | Jobs | -| ------------------------ | ------------------------ | --------------------------- | -| `Deploy to GitHub Pages` | push в `main`, dispatch | `verify`, `build`, `deploy` | -| `Quality` | `pull_request`, dispatch | `verify`, `e2e` | +| Workflow | Триггер | Jobs | +| ------------------------ | --------------------------------------- | --------------------------- | +| `Deploy to GitHub Pages` | push в `main`, dispatch | `verify`, `build`, `deploy` | +| `Quality` | push в `main`, `pull_request`, dispatch | `verify`, `e2e` | -Следствие: при прямом пуше в `main` выполняется только быстрый gate — `verify` -внутри deploy-workflow. Browser matrix из четырёх проектов на этом прогоне не -запускается вообще, поэтому зелёный deploy-run нельзя читать как «e2e прошёл». +Пуш в `main` запускает оба workflow: deploy проверяет быстрый gate и собирает +сайт, `Quality` прогоняет тот же `verify` и browser matrix. Дублирование +`verify` (~1 мин) сознательное: matrix на каждый пуш стоит ~3 мин, и условные +job-и ради минуты не окупаются. Browser matrix проверяется на каждом пуше, а +ручной `gh workflow run quality.yml` нужен только для перепрогона старого +коммита. ### Проверка результатов CI после пуша @@ -99,17 +102,17 @@ per-project лимит воркеров, а browser matrix упирается в память Linux-раннера отличаются. Поэтому после пуша разработчика: 1. дождаться завершения workflow и посмотреть, какие job вообще запустились; -2. отдельно открыть non-blocking `e2e`, если он был в прогоне: его красный - статус не блокирует PR, но остаётся падением, и его нельзя выдавать за - «зелёный по умолчанию»; -3. если `e2e` не запускался (прямой пуш в `main`), сказать это прямо: matrix на - раннере ещё не проверена, и её можно прогнать через PR или - `gh workflow run quality.yml`; -4. сообщить фактический результат (passed, failed, skipped) в отчёте агента. - -Красный `e2e` только из-за ресурсов раннера фиксируется как ограничение -окружения: сначала проверяется один проект и один spec, а не увеличиваются -таймауты под конкретную машину. +2. смотреть статусы **отдельных job**, а не общий conclusion прогона: у `e2e` + стоит `continue-on-error: true`, поэтому прогон с упавшим e2e целиком + помечается как `success` — проверено на run `36225579363` (`E2E: failure` при + `conclusion: success`); +3. если `e2e` запускался и зелёный — сообщить фактические числа passed, failed, + skipped; +4. если `e2e` не запускался, сказать это прямо: matrix на раннере не проверена, + и её можно прогнать через `gh workflow run quality.yml`; +5. красный `e2e` только из-за ресурсов раннера фиксируется как ограничение + окружения: сначала проверяется один проект и один spec, а не увеличиваются + таймауты под конкретную машину. ### Измеренная стоимость прогона