При выпуске каждой новой версии пакета коммиту должен проставляться тэг с названием этого пакета и версией:
@csssr/[email protected].
Новые версии выпускаются только с ветки master после слития туда релизной ветки.
В работе с ветками используется адаптированный git-flow подход.
Если в двух словах, то git-flow упрощает и упорядочивает работу с ветками. Для каждого вида работы отводится определенная ветка. Существуют следующие ветки: master, develop, feature, fix и release.
Основной (максимально стабильный) код хранится в ветке master.
Новый функционал разрабатывается в ветках feature.
В ветках fix происходит фикс багов.
Разработка ведется в ветке develop, куда следует направлять Pull Request-ы feature и fix веток. Из этой ветки отпачковыется ветка release.
В release копятся изменения, исправляются ошибки перед очередным обновлением master.
Название веток с фичами или фиксами должны начинаться с префиксов feature/ и fix/,
далее за которым обычно идет номер issue из JIRA, а после — короткое описание на английском.
Примеры:
feature/CORE-99-awesome-feature // Правильно
feat/CORE-99-awesome-feature // Неправильный префикс
fix/awesome-fix // Нежелательно, не указан issueId
fix/CORE-100 // Нежелательно, нет короткого описания
Сообщение коммита (commit message) должно быть валидным в соответствии с conventional commits, это строго контролируется precommit-хуком.
В сообщении коммита желательно всегда указывать номер задачи, если это возможно.
Сам текст сообщения пишется на русском языке, с заглавной буквы.
Примеры:
feat: CORE-99 Добавил обалденную штуку // Правильно
fix: СORE-99 Добавил обалденную штуку // Неправильный префикс, т.к. была добавлена фича
fix: Исправил странный баг // Нежелательно, не указан issueId
chore(webpack): CORE-9 Поправил сборку // Правильно, с указанием scope даже лучше
Это монорепозиторий, в котором хранится код нескольких пакетов, каждый из которых имеет независимую версию, и некоторые из них публикуются в npm.
За поднятие версии в package.json файлах пакетов и публикацию их в npm отвечает lerna,
настроеная в independent режиме.
Анализируя новые коммиты и тэги репозитория, lerna понимает, какую (и можно ли) выпустить версию. Благодаря conventional commits и анализу измененных с момента выпуска последней версии файлов, lerna может автоматически определить, какая версия какого пакета должна быть выпущена.
Для этого нужно:
- Слить всё новое в ветку
master; - Запустить команду:
yarn lerna version --conventional-commits --no-changelog --yes;
Lerna внесет изменения в package.json файлы пакетов (поднимет версии), закоммитит их,
выставит теги и сделает push в удаленный репозиторий.
Следующим этапом нужно опубликовать пакеты: yarn lerna publish from-git --yes
Новые версии пакетов должны быть опубликованы. Можно быстро проверить результат публикации:
# Скачиваем архив с пакетом @csssr/core-design и распаковываем
$ npm v @csssr/core-design dist.tarball | xargs curl | tar -xz
# Переходим в директорию и смотрим версию
$ cd package && cat package.json | grep "version"
# Удаляем временную папку
$ cd .. && rm -rf ./package
Процесс сборки описан в другом месте, в этом документе приведены некоторые уточнения по автоматизированной работе Депломата.
Депломат (на май 2019 года) не умеет пропускать сборку, которая была вызвана push-эвентом с коммитом, сообщение которого имеет
что-то наподобие [ci skip].
Выполняя приведенные выше команды для поднятия версии (выполняет их Депломат при push-e в ветку master)
в репозиторий попадает новый коммит, и процесс публикации нарушается, т.к. запускается ещё одна сборка.