Как сделать автодеплой UI kit на NPM с помощью gitlab CI/CD

[Lavich]

1. Все токены для безопасности лучше всего убрать из кода в переменные окружения

2. У "версии" не спроста есть три уровня - они показывают насколько сильно изменился пакет. Подробнее можно почитать вот здесь, например, https://semver.org/lang/ru/

3. Этот js-скрипт можно было бы запускать в pre-push, использовав, например, husky. Тогда можно было бы избежать возни с токеном гитлаба. А запуск деплоя новой версии в npm-репозиторий можно привязать к изменению версии в package.json

[Dragonek]

1. С токенами согласен, показывал как максимально просто сделать

2. Спасибо большое, почитаю!

3. Думал об этом, возможно дополню статью

[mdlufy]

Этот js-скрипт можно было бы запускать в pre-push

Инкремент версии в pre-push? Кажется это нужно делать после всех джоб, чтобы лишний раз не занимать время при разработке. К тому же билд упасть же может

[Dragonek]

Я видел, как в некоторых компаниях в pre-push прогоняются тесты и собирается билд, так что думаю в некоторых случаях это все таки применимо) Поэтому я бы не исключал этот вариант

[alxsk]

Про версии, я бы дополнил, что в принципе не особо сложно сделать автоматическую инкрементацию согласно semantic versioning, если на проекте используются (и главное соблюдаются) conventional commits. Подробнее тут можно почитать: https://www.conventionalcommits.org/en/v1.0.0/

Общая идея:

1. При релизе/деплое: достаем список ченджей гита с прошлого релиза (по тэгу)

2. Смотрим какие были изменения (фиксы, фичи, ломающие изменения). Если что, для анализа conventional commits, генерации по нему change-list'ов и прочего есть готовые либы.

3. Инкрементируем версию: патч - только фиксы, минор - фиксы + фичи, мажор - наличие ломающих изменений

4. Публикуем/деплоим

5. Пушим коммит с новой версией, плюс вешаем тег

Вообще, conventional commits дает очень много профита, особенно на больших долгоиграющих проектах.

[Dragonek]

Согласен, было бы красиво) Подумаю над этим.