VerificationWorkflow

Что это

VerificationWorkflow — это и есть весь CI фабрики. Другого CI нет: ни Forgejo Actions, ни альтернативных маршрутов. Это отдельный, дочерний workflow (в отличие от главного DevPipeline), который проверяет один конкретный коммит.

На вход он получает два значения — репозиторий и коммит (ref):

VerificationInput(
    repo = "forgejo.example.com/org/repo",   # какой репозиторий
    ref  = "9f2c…",                           # какой коммит проверить (SHA)
)

Откуда запускается — два пути

Проверку запускают двумя способами, но оба ведут в один и тот же VerificationWorkflow:

# путь А — родительский DevPipeline запускает дочерний workflow на SHA шага
await workflow.start_child_workflow(
    VerificationWorkflow.run,
    VerificationInput(repo=_DEFAULT_VERIFICATION_REPO, ref=commit_sha),
    id=f"{workflow_id}:{step_name}:verify",
)

# путь Б — вебхук стартует workflow на коммите события
await client.start_workflow(
    VerificationWorkflow.run,
    VerificationInput(repo=repo, ref=target.ref),
    id=f"webhook:{repo}:{ref}",
)

Что именно проверяется

Workflow сам ничего про «как проверять» не знает. Он читает команду из .meeseeks/project.yml репозитория — секцию verify.command:

# .meeseeks/project.yml — что значит «проверка пройдена»
verify:
  command: "make test && make lint"

Парсинг — в domain/project_config.py. Если поле verify.command отсутствует или пусто — workflow падает с явной ошибкой MissingVerifyCommandError (не гадает, что запускать).

Как исполняется — verify-джоба в Nomad

Сама проверка исполняется не в воркере, а в Nomad-джобе verify (nomad/verify.nomad.hcl) — по той же причине, по которой агенты бегают в Nomad: изоляция. Группа джобы собирается из четырёх тасков:

Три таска делят одну bridge-сеть — поэтому verify ходит к docker-демону по tcp://127.0.0.1:2375. Это исполнение закрыто задачей CI-9.

Переиспользует готовое — без своего велосипеда

VerificationWorkflow не переизобретает доставку кода. Чтение project.yml идёт через activity load_project_config, которая клонирует репозиторий read-only тем же каналом, что и агент (NM-2 → NM-5):

• RepoCloner.clone_repo_snapshot — тот же read-бот Forgejo → снапшот в MinIO.
• Снапшот читается git show <ref>:path — без чекаута, поэтому разрешается любой исторический коммит, а не только текущий HEAD.
• Write-доступа нет вообще: deploy-ключи (NM-3) в этот модуль не попадают.

Вердикт и его публикация (CI-7 — текущая задача)

После прогона у коммита появляется commit-status в Forgejo — тот самый «зелёный/красный», который видит человек и дев-ревьюер в MR:

Домен — источник истины: вердикт считается здесь, Forgejo — зеркало. Публикация — отдельная activity под RetryPolicy; недоступность Forgejo не теряет вердикт. Подробнее — на странице задачи CI-7.

Связь с задачами