Прочитайте простой workflow GitHub Actions и объясните, что его запускает и что он делает

Короткий ответ

Workflow запускается при push в любую ветку репозитория и при открытии/обновлении pull request в ветку `main`; при срабатывании он выполняет одну джобу `build`, которая скачивает код, устанавливает зависимости и запускает тесты на Ubuntu-раннере.

Как это работает подробнее

блок `on` определяет события-триггеры (`push`, `pull_request`), `jobs` описывает, какие задачи выполнять и на какой среде (`runs-on: ubuntu-latest`), а `steps` — последовательные шаги внутри джобы, включая готовые переиспользуемые actions (`actions/checkout`, `actions/setup-node`).

Пример кода

example.yamlКопировать

name: CI
on:
  push:
    branches: ["**"]
  pull_request:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "20"
      - run: npm ci
      - run: npm test

Что использовать на практике

• На практике. такой минимальный workflow — типичная отправная точка для CI: он не деплоит ничего, а только проверяет код. Для реального проекта к нему обычно добавляют кэширование зависимостей, линтер и отдельный workflow или джобу для деплоя, запускаемую по более узкому условию (например, только на `main`).
• Пример. Ожидаемое поведение: при любом push появляется новый workflow run на вкладке Actions; на вкладке pull request отображается статус-чек `CI / build` с результатом (успех/провал) выполнения тестов.

Подводные камни

• Частые ошибки. путают `pull_request` (код из форка/ветки, обычно без доступа к секретам) с `pull_request_target` (код из целевой ветки, с доступом к секретам, что рискованно для PR из форков); не указывают версию `actions/checkout@vX`, из-за чего поведение workflow может незаметно измениться при обновлении action.