Кэширование, секреты и развёртывания — Примеры
Пример 1 — Кэш, который вечно отдаёт устаревшие зависимости
Каждый прогон заново ставит всё дерево зависимостей, поэтому был добавлен шаг кэша ниже. Неделю он помогал, а потом сделал воспроизводимым несвязанный отказ. Объясните ключ и исправьте шаг.
- uses: cache
with:
path: ~/.npm
key: node-deps
Решение
- uses: cache
with:
path: ~/.npm
key: deps-${{ runner.os }}-${{ hashFiles('package-lock.json') }}
Кэш с ключом из константы — это кэш, который никогда не может промахнуться, поэтому первый набор зависимостей восстанавливается бесконечно, даже после изменения файла блокировки. Ключ по хешу файла блокировки означает, что изменение зависимости даёт промах, а все остальные прогоны попадают в кэш и установка пропускается. Это единственная настройка, решающая, будет быстрый конвейер быстрым и верным или только быстрым.
Пример 2 — Прошедшая проверка, которая заодно и релиз
Рабочий процесс ниже запускается на pull request’е и заканчивается задачей развёртывания, держащей продакшен-учётные данные. Ветка участника может поэтому дотянуться до продакшена без решения человека. Перестройте рабочий процесс так, чтобы проверки и релиз были раздельны.
on: pull_request
jobs:
test:
runs-on: ubuntu-latest
steps: [{ run: ./run-tests.sh }]
deploy:
needs: test
runs-on: ubuntu-latest
steps: [{ run: ./deploy.sh }]
Решение
on:
pull_request:
push:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps: [{ run: ./run-tests.sh }]
deploy:
if: github.ref == 'refs/heads/main'
environment: production
runs-on: ubuntu-latest
steps: [{ run: ./deploy.sh }]
Проверка сообщает, хорошее ли изменение; развёртывание меняет то, что работает у пользователей, поэтому задача развёртывания теперь идёт только для основной ветки и ждёт окружения, требующего одобрения. Эта задача — ещё и единственное место, где должны жить учётные данные, потому что токен рабочего процесса обычно шире, чем нужно задаче.
Подставьте свои имена действий, имена окружений и файлы репозитория там, где в этих набросках стоят заглушки.