CI для контрактов: автотесты в GitHub Actions
Подключишь полный GitHub Actions workflow: install, blueprint build и npm test на каждый push и PR.
Зачем CI контрактам
Каждый push должен подтверждать: контракт собирается, wrappers актуальны, Sandbox-тесты зелёные. Иначе «у меня локально работает» доезжает до review уже сломанным.
Ниже — рабочий workflow для типичного Blueprint-проекта (Node 22, npx blueprint build, npm test).
Полный workflow-файл
Создай .github/workflows/ton-contracts.yml в корне репозитория:
Если пакетный мененер — pnpm:
Секреты сети для CI не нужны, пока тесты идут только в @ton/sandbox. Ключи mainnet/testnet в Actions добавляй только для отдельного job деплоя — и никогда в логи.
Как это работает
npm ci— воспроизводимая установка по lockfile (предпочтительнееnpm installв CI).blueprint build --all— компилирует все контракты; падение компилятора валит pipeline до тестов.npm test— Jest + локальный Blockchain из@ton/sandbox, без RPC.concurrency— отменяет устаревший прогон на тот же branch при новом push.
Частые ошибки
В CI стоит Node 18, а локально 22 → разные результаты/несовместимые пакеты. Зафиксируй node-version: "22" как в установке окружения.
Нет lockfile, используешь npm install → «плавающие» версии ломают build через неделю. Коммить package-lock.json / pnpm-lock.yaml и используй ci / --frozen-lockfile.
Кладешь mnemonic в env job'а для unit-тестов → не нужно и опасно. Sandbox не требует реальных ключей; для деплоя — отдельный protected environment.
Что дальше
- Blueprint: структура проекта и конфигурация — что именно собирает CI
- TON Sandbox: локальное тестирование — как устроены тесты
- Sandbox unit-тесты контракта — паттерны проверок
Материалы gramdocs.tech носят образовательный характер и не являются финансовой, юридической или инвестиционной рекомендацией. Работа с блокчейном TON и токеном Gram связана с рисками потери средств. Правовая информация