Інструменти CI: GitHub Actions, GitLab CI, Jenkins

Що таке «пайплайн як код» (pipeline as code) і чим він кращий за налаштування збірки кліками?

Це підхід, за якого весь пайплайн описано текстовим файлом, що лежить у репозиторії поруч із кодом, а не галочками у вебінтерфейсі сервера. Стара freestyle-модель, де адміністратор руками проставляв кроки в браузері, дає чотири болючі мінуси: нема історії змін, нема рев'ю, конфіг не відновиш після падіння сервера й він не їде разом із гілкою. Файл у репо лікує все одразу: кожну правку видно через git blame, зміну переглядають у звичайному pull request, клон репозиторію відтворює пайплайн повністю, а feature-гілка може нести власну версію кроків. Формат майже завжди декларативний YAML — ти кажеш що має статися, а не пишеш покрокову інструкцію як. На співбесіді від тебе чекають саме ці чотири вигоди: версіонування, рев'ю, відтворюваність і подорож із гілкою.

З яких рівнів складається модель GitHub Actions і як вони пов'язані?

Рівнів чотири, і плутанина між ними — класична помилка новачка. Workflow — це один YAML-файл у теці .github/workflows/; проєкт може мати їх кілька (окремо тести, окремо деплой). Кожен workflow стартує у відповідь на event (подію) із секції on: — push, pull_request, schedule, workflow_dispatch. Усередині — jobs (джоби), кожен на своєму свіжому runner, а всередині джоба — steps (кроки), які йдуть строго послідовно. Крок — це або run: (shell-команда), або uses: (готовий action, наприклад actions/checkout). Сильна відповідь одразу показує цю ієрархію: подія запускає workflow, той містить паралельні джоби, кожен складається з послідовних кроків.

Тригер on: push спрацьовує на git commit чи на git push? Чому різниця критична?

На git push, бо подія відбувається на сервері GitHub, а не на твоєму диску. Локальний commit записує зміну лише в твій репозиторій — сервер про неї ще нічого не знає, отже й CI мовчить. Пайплайн прокидається тільки тоді, коли коміти доїхали на віддалений сервер через push. Це прямий наслідок межі «Git — це не GitHub»: локальна система контролю версій і хостинг — різні речі. Практичний висновок: якщо чекаєш зеленого прогону, а його нема — перше питання «а ти взагалі запушив?».

Джоби в пайплайні виконуються послідовно чи паралельно за замовчуванням?

Паралельно — і це головна пастка на розуміння моделі виконання. У GitHub Actions усі джоби workflow за замовчуванням стартують одночасно, кожен на окремій машині; у GitLab CI паралельно біжать джоби в межах однієї стадії. Послідовність — це те, що треба задати явно: у GitHub через ключ needs:, у GitLab через порядок стадій або той самий needs:. Типовий наслідок помилки: тест, який залежить від складеного артефакту, без needs: стартує на порожньому місці, бо збірка ще не завершилась. А от кроки всередині одного джоба — навпаки, завжди строго послідовні.

Як у GitHub Actions змусити один джоб дочекатися іншого?

Через ключ needs: у залежному джобі — він перелічує імена джобів, які мусять завершитися успішно перед його стартом. Наприклад, джоб deploy із needs: [build, test] не почнеться, поки обидва не стануть зеленими. Без цього обидва джоби вважаються незалежними й запустяться одночасно, що для «збери → протестуй → задеплой» зламає логіку. По суті needs: перетворює плаский набір паралельних джобів на граф залежностей. У GitLab той самий ключ needs: дозволяє порушити суворий порядок «стадія за стадією» й теж побудувати граф.

Чим структура GitLab CI відрізняється від GitHub Actions?

GitLab пішов шляхом «один файл на весь проєкт»: замість теки з багатьма workflow-файлами тут єдиний .gitlab-ci.yml у корені репозиторію. Його модель крутиться навколо двох понять — stages і jobs: спершу оголошуєш список стадій у порядку виконання, потім описуєш джоби й кожен прив'язуєш до стадії ключем stage:. Правило залізне: стадії йдуть послідовно, а джоби в межах однієї стадії — паралельно, і наступна стадія стартує лише коли всі джоби попередньої зелені. Docker-образ джоба задають ключем image:, команди — секцією script:, умовний запуск — rules:. Готового «маркетплейсу» тут немає: повторне використання роблять через include: і шаблони.

Що таке стадія (stage) у GitLab і як вона співвідноситься з джобами?

Стадія — це явна іменована фаза пайплайна (наприклад build, test, deploy), а джоб — конкретна одиниця роботи всередині неї. Спершу ти оголошуєш список стадій у порядку їх виконання, а далі кожен джоб кидаєш у потрібну стадію ключем stage:. Модель проста: усі джоби однієї стадії стартують разом і біжать паралельно, а перехід до наступної стадії відбувається тільки після того, як уся попередня стала зеленою. Важлива відмінність від GitHub Actions: там рівня «стадія» взагалі немає — є лише джоби та їхні зв'язки через needs:, а візуальні групи в UI похідні від цих зв'язків. У GitLab же стадія — явна й обов'язкова частина моделі.

Чим run: відрізняється від uses: у кроці GitHub Actions?

Це два способи задати, що робить крок. run: виконує звичайну shell-команду — npm ci, npx playwright test; ти просто пишеш те, що набрав би в терміналі. uses: підключає action — готовий переиспользуваний блок, свій або зі спільного каталогу GitHub Marketplace: actions/checkout викачує код репозиторію, actions/setup-node ставить Node.js. Тобто run: — це «зроби ось цю команду», а uses: — «використай ось цю цеглинку, яку хтось уже написав». Саме ці екшени-цеглинки й дали назву всьому інструменту. Плутати action, job і step не можна: джоб — окрема машина, крок — дія всередині неї, екшен — те, що крок підключає через uses.

Freestyle job проти Jenkinsfile — у чому різниця й чому це часто ловлять на співбесіді?

У Jenkins фактично живуть два світи. Legacy — freestyle job: та сама «конфігурація кліками» через вебморду, з галочками й командами в текстових полях; величезна кількість старих проєктів досі так працює, тож на реальній роботі ти це зустрінеш, але це антипатерн — не версіонується, не рев'ю́ється, крихке. Сучасний світ — Pipeline, описаний файлом Jenkinsfile у репозиторії мовою Groovy, той самий pipeline as code. На співбесіді провалюються ті, хто ототожнює Jenkins із «конфігом кліками»: правильна відповідь розрізняє ці два світи й знає, що сучасний Jenkins тримає пайплайн у репо, як і решта інструментів.

Declarative проти scripted пайплайна в Jenkins — коли який?

Це два стилі опису Jenkinsfile. Declarative — структурований, із фіксованими секціями (pipeline, agent, stages, stage, steps, post); він рекомендований за замовчуванням, бо читабельний і має чіткі рамки. Scripted — повноцінний імперативний Groovy: гнучкіший, дозволяє складну логіку, але й складніший та легше стріляє в ногу. На практиці більшість проєктів пише declarative, а до scripted вдаються, коли треба щось, чого декларативний формат не дозволяє. Для AQA корисна деталь declarative-стилю — секція post із блоками always/success/failure: вона виконується після пайплайна й ідеально підходить, щоб зберегти звіт і скриншоти незалежно від результату тестів.

Чому слово «job» у Jenkins означає не те саме, що в GitHub і GitLab?

Бо це різні рівні анатомії під однією назвою. У GitHub і GitLab job — це одиниця, що виконується на окремій машині-виконавці. У Jenkins ту роль «одиниці, що біжить у своєму оточенні» грає радше stage, а слово «job» позначає весь пайплайн цілком. Тому механічний переклад «job = job» через три інструменти вводить в оману: правильний мапінг — джоб GitHub/GitLab ↔ стадія Jenkins. Це одна з двох головних пасток словника-перекладача; друга — що в GitHub Actions рівня «стадія» взагалі немає, тоді як у GitLab він явний.

Опиши мінімальний workflow прогону автотестів у CI.

Послідовність універсальна, хоч у GitHub Actions, хоч у GitLab, хоч у Jenkins — змінюються лише ключові слова. Крок 1 — checkout: викачати код репозиторію на runner, інакше нема що тестувати. Крок 2 — setup: поставити потрібну версію середовища (наприклад Node.js). Крок 3 — детермінована установка залежностей (npm ci). Крок 4 — докачати браузери та системні бібліотеки (npx playwright install --with-deps). Крок 5 — сам прогін (npx playwright test), чий ненульовий код виходу робить джоб і весь пайплайн червоним — це і є сигнал CI. Крок 6 — зберегти HTML-звіт як артефакт, обов'язково з умовою «навіть якщо тести впали». Плюс варто згадати, що запуск вішають і на push, і на pull_request.

Навіщо на кроці збереження звіту ставлять if: always()?

Щоб артефакт зберігся навіть після червоного прогону — саме тоді, коли він найпотрібніший. За замовчуванням, коли попередній крок (npx playwright test) впав з ненульовим кодом, наступні кроки джоба пропускаються — і крок вивантаження звіту теж не виконається. if: always() каже «виконай цей крок незалежно від того, що було раніше», тож HTML-звіт, трейси й скриншоти доїдуть до артефактів попри падіння тестів. У GitLab той самий сенс дає when: always у секції artifacts:, у Jenkins — блок post { always { ... } }. Забути це — типова помилка: тести червоні, доказів нема, дебажити ні по чому.

npm ci проти npm install — чому в CI беруть саме ci?

Бо npm ci детермінований і призначений спеціально для автоматизованих середовищ. Він ставить залежності строго за package-lock.json, не змінюючи його, і починає з чистого node_modules — тобто дає точно відтворюваний набір версій від прогону до прогону. npm install натомість може оновити lock-файл і підтягнути новіші сумісні версії, через що збірка стає невідтворюваною: локально одне, у CI інше. Для пайплайна відтворюваність критична — червоний тест має падати через код, а не через те, що вночі приїхала інша мінорна версія залежності. Тому в CI-скриптах майже завжди саме ci.

Як на проєкті обирають CI-інструмент і коли свідомо беруть Jenkins?

Чесна відповідь, яка часто дивує кандидатів: найчастіше інструмент не обирають — його диктує хостинг коду. Код на GitHub → природно GitHub Actions, воно вже вбудоване; код у GitLab → GitLab CI з тієї ж причини. Ці два «вбудовані» варіанти виграють за замовчуванням завдяки нульовому порогу входу. Jenkins беруть свідомо, коли є вагома причина: self-hosted і закритий контур (дані не можна віддавати в хмару), уже готова роками інфраструктура з десятками плагінів, екзотична інтеграція, для якої існує лише Jenkins-плагін, або незалежність від git-хостингу. Практичний висновок для AQA: інструмент — деталь, анатомія «тригер → джоби → кроки → артефакти» спільна, і хто розуміє модель, за годину освоює будь-який із трьох.

Що таке JUnit XML і навіщо він у CI?

Це універсальний текстовий формат звіту про результати тестів, який уміють читати всі три інструменти. Playwright (як і більшість фреймворків) уміє його генерувати, і саме через нього CI показує впалі тести прямо в інтерфейсі, а не змушує рити текстовий лог. GitLab підтягує його секцією artifacts:reports:junit і підсвічує падіння прямо в merge request, Jenkins — через junit-плагін, GitHub — через сторонні екшени-репортери. По суті це місток між прогоном і UI: він перетворює «щось червоне в логах» на структурований список конкретних впалих кейсів. Для дебагу це економить час — видно, який саме тест і чому впав, без гортання простирадла stdout.

Чому не можна просто перенести YAML із GitHub Actions у GitLab CI?

Бо в них спільна лише анатомія, а не текст. Синтаксис несумісний на всіх рівнях: різні імена ключів (jobs/steps/uses проти stages/script/image), різна модель виконання (у GitLab явні стадії, у GitHub їх нема), різні вирази для секретів і умов. Скопійований файл або не розпарситься, або зробить не те. Правильний спосіб «перенести» пайплайн — узяти ту саму модель (тригер → джоби → кроки → артефакти) і переписати її ключовими словами цільового інструмента. Окремо варто пам'ятати, що в YAML відступ — це синтаксис: зайвий пробіл ламає весь пайплайн малозрозумілою помилкою парсера, і добра частина «зелений код, червоний CI на порожньому місці» — це саме биті відступи.

Три ситуації, у яких AQA щодня стикається з CI-інструментами: прочитати той самий прогін трьома діалектами, не втратити звіт після червоного прогону і розшифрувати чужий конфіг на новому проєкті. Скрізь — що дивитися і чому.

Кейс 1. Один прогін — три діалекти

Задача одна: на кожен push і pull request прогнати Playwright-тести й зберегти звіт. Нижче — той самий флоу трьома інструментами. Анатомія ідентична (тригер → джоб → кроки → артефакт), змінюються лише ключові слова.

GitHub Actions — .github/workflows/e2e.yml:

name: e2e-tests
on:
  push:
    branches: [main]
  pull_request:
jobs:
  playwright:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/

GitLab CI — .gitlab-ci.yml:

stages:
  - test
e2e:
  stage: test
  image: mcr.microsoft.com/playwright:v1.44.0-jammy
  script:
    - npm ci
    - npx playwright test
  artifacts:
    when: always
    paths:
      - playwright-report/

Jenkins — Jenkinsfile (declarative):

pipeline {
    agent { docker { image 'mcr.microsoft.com/playwright:v1.44.0-jammy' } }
    stages {
        stage('Install') { steps { sh 'npm ci' } }
        stage('Test')    { steps { sh 'npx playwright test' } }
    }
    post {
        always {
            archiveArtifacts artifacts: 'playwright-report/**', allowEmptyArchive: true
        }
    }
}

Що дивитися і чому:

• Один рядок словника-перекладача бачиш наживо. «Крок» — це run: у GitHub, рядок у script: у GitLab і sh у Jenkins. «Готовий блок» — uses: actions/setup-node у GitHub, а в GitLab та Jenkins ту саму роль грає image: з готовими браузерами, тож окремий крок установки не потрібен.
• Збереження звіту — три написання однієї ідеї. if: always(), when: always і post { always { ... } } роблять те саме: віддають артефакт навіть після червоного прогону. Приберіть цю умову — і при падінні тестів звіт не збережеться.
• npm ci, а не install, скрізь однаково. Детермінована установка з package-lock.json — те, що робить прогін відтворюваним від запуску до запуску; це властивість не інструмента, а дисципліни.
• Перенести текст «як є» не вийде. Ключі, модель стадій і вирази несумісні — спільна лише анатомія. Тому «переписати пайплайн під інший CI» означає перекласти модель, а не скопіювати файл.

Кейс 2. Тести червоні — а звіту немає

Найдорожча дрібниця в конфізі автотестів. Уяви workflow, де крок збереження артефакту написали без умови:

      - run: npx playwright test
      - uses: actions/upload-artifact@v4   # ❌ немає if: always()
        with:
          name: playwright-report
          path: playwright-report/

Поки тести зелені — усе працює. Але щойно npx playwright test завершується ненульовим кодом (тобто щось упало), джоб позначається як провалений, і всі наступні кроки пропускаються — зокрема й вивантаження звіту. Результат парадоксальний: звіт є рівно тоді, коли він не потрібен, і зникає рівно тоді, коли потрібен найбільше. Дебажити червоний прогін ні по чому — ні HTML-звіту, ні трейсів, ні скриншотів.

Виправлення — один рядок:

      - run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: always()                       # ✅ зберегти незалежно від результату тестів
        with:
          name: playwright-report
          path: playwright-report/

Що дивитися і чому:

• if: always() не ховає падіння тестів. Джоб усе одно лишається червоним (це визначає код виходу playwright test) — умова впливає тільки на те, чи виконається крок збереження. Ти отримуєш і чесний червоний статус, і докази.
• У GitLab і Jenkins та сама пастка з іншими словами. Без when: always у секції artifacts: GitLab викине звіт при падінні; без post { always } те саме зробить Jenkins. Умова «завжди» — не косметика, а частина коректного конфігу.
• Це перше, що варто перевірити в чужому пайплайні. Якщо колеги скаржаться «тест червоний, а подивитися нема на що» — дивись, чи є умова always на кроці артефакту.

Кейс 3. Зелений локально, червоний у CI на порожньому місці

Ти прийшов на новий проєкт, у репо вже лежить .gitlab-ci.yml, і твій новий джоб e2e падає ще до першого тесту. Два найчастіші винуватці — порядок джобів і биті відступи.

Порядок джобів. Припустимо, конфіг такий:

stages:
  - build
  - test
build-app:
  stage: build
  script: [ npm run build ]
e2e:
  stage: build          # ❌ помилково в тій самій стадії, що й збірка
  script: [ npx playwright test ]

e2e і build-app опинилися в одній стадії build, а джоби всередині стадії біжать паралельно. Тести стартують одночасно зі збіркою — на порожньому місці, бо застосунок ще не зібрано. Лікування: винести e2e у стадію test (яка йде після build), або в GitHub Actions додати залежному джобу needs: [build-app]. Правило, яке рятує від цілого класу таких падінь: за замовчуванням джоби паралельні, послідовність задають явно.

Биті відступи. У YAML відступ — це синтаксис, а не форматування. Зайвий пробіл перед ключем ламає весь пайплайн малозрозумілою помилкою парсера, хоча код застосунку бездоганний:

e2e:
  stage: test
   script:               # ❌ зайвий пробіл — script «випав» із джоба
    - npx playwright test

Що дивитися і чому:

• «Червоний CI на порожньому місці» частіше про конфіг, ніж про код. Перш ніж підозрювати застосунок, перечитай сам YAML: відступи, стадію джоба, наявність needs:.
• Спершу відтвори модель у голові. Постав питання «цей джоб від чогось залежить?» і «він точно в правильній стадії?» — це знімає більшість гонок «тест стартував раніше за збірку».
• Помилку парсера читай буквально. Повідомлення на кшталт «did not find expected key» майже завжди вказує на відступ, а не на логіку — шукай зсув на пробіл, а не переписуй кроки.

Pipeline as code

• Можу назвати чотири вигоди підходу «пайплайн як код»: версіонування, рев'ю в PR, відтворюваність, конфіг подорожує з гілкою.
• Знаю, чому freestyle-модель (налаштування кліками) — антипатерн: нема історії, нема рев'ю, конфіг не відновиш і не візьмеш у гілку.

GitHub Actions

• Знаю чотири рівні моделі: workflow → event (on:) → jobs → steps, і не плутаю їх між собою.
• Можу пояснити різницю run: (shell-команда) vs uses: (готовий action на кшталт actions/checkout).
• Знаю, що workflow-файли лежать у теці .github/workflows/ і їх може бути кілька на проєкт.

GitLab CI

• Знаю, що весь пайплайн описано одним файлом .gitlab-ci.yml у корені репозиторію.
• Можу пояснити модель stages + jobs: стадії послідовні, джоби всередині стадії паралельні.
• Знаю ключі джоба: script: (команди), image: (Docker-образ), rules: (умовний запуск), artifacts:/cache:.

Jenkins

• Розрізняю два світи Jenkins: legacy freestyle (кліки) і сучасний Jenkinsfile (pipeline as code).
• Знаю різницю declarative (структурований, рекомендований) vs scripted (імперативний Groovy, гнучкіший) пайплайна.
• Розумію секцію post з блоками always/success/failure і чому вона зручна для збереження звіту AQA.

Мапінг і модель виконання

• Знаю пастку: «job» у Jenkins — це радше stage, а сам job у Jenkins — весь пайплайн.
• Пам'ятаю, що в GitHub Actions рівня «стадія» немає (лише needs:), а в GitLab стадія явна й обов'язкова.
• Твердо знаю: джоби за замовчуванням паралельні, послідовність задають через needs: або стадії; кроки в джобі — навпаки, послідовні.

Прогін автотестів і артефакти

• Можу з голови описати мінімальний прогін: checkout → setup → залежності → браузери → тест → артефакт-звіт.
• Розумію, чому в CI беруть npm ci, а не npm install (детермінована, відтворювана установка з lock-файлу).
• Пам'ятаю обов'язковість if: always() (GitHub) / when: always (GitLab) / post { always } (Jenkins) для звіту при падінні.
• Розумію роль JUnit XML як універсального містка, що показує впалі тести в UI CI замість тексту логу.

Вибір інструмента

• Можу пояснити, що інструмент найчастіше диктує хостинг коду: GitHub → Actions, GitLab → GitLab CI.
• Знаю причини свідомо взяти Jenkins: self-hosted/закритий контур, готова інфраструктура, екзотичний плагін, незалежність від git-хостингу.