Тест на оформлення замовлення локально проходить 50 разів з 50. У GitHub Actions падає приблизно в третині запусків з таймаутом на кроці:
await expect(page.getByText('Замовлення оформлено')).toBeVisible();Ретраї іноді рятують. Як знайти причину, а не просто збільшити таймаут?
Класика. Майже завжди причина в одному з цих пунктів:
1. Ресурси CI. Раннер має 2–4 ядра, а локально у вас 12. Якщо в конфігурації workers не обмежено, на CI запускається кілька браузерів одночасно і все гальмує. Спробуйте workers: process.env.CI ? 2 : undefined.
2. Спільні тестові дані. Паралельні тести використовують одного користувача чи один кошик — і заважають одне одному. Локально ви, ймовірно, запускаєте тест сам по собі. Перевірка: npx playwright test --workers=4 --repeat-each=10 локально — якщо почне падати, причина тут.
3. Інше оточення. Локально — localhost з порожньою базою, у CI — спільний staging з повільнішим бекендом або сторонній сервіс (платіжний шлюз у тестовому режимі) відповідає 10+ секунд.
4. Таймзона й локаль. Раннер працює в UTC з англійською локаллю: дати, формати чисел і навіть тексти можуть відрізнятися. Задайте явно в конфігурації: use: { locale: 'uk-UA', timezoneId: 'Europe/Kyiv' }.
Щоб не гадати — увімкніть трасування для повторних спроб (trace: 'on-first-retry') і завантажуйте звіт як артефакт. У трасуванні буде видно, на якому мережевому запиті все зависло: часто це відповідь API, яка в CI йде 20 секунд.
З боку інфраструктури: перевірте, чи не стоїть тест у черзі за холодним стартом застосунку. Якщо в пайплайні піднімається свіже середовище, перші запити після деплою можуть бути повільними (прогрів, міграції, JIT). Додайте крок, який чекає /ready ендпоінт перед запуском тестів, — і частина «флакі» зникне.
Увійдіть через Google — і зможете відповідати, голосувати й ставити власні питання. Це безкоштовно.
Увійти через Google