Skip to main content

Интеграция в гитлабе

Для внедрения мы сделаем:

  • Установим зависимости
  • Сконфигурируем package.json
  • Сконфигурируем pvm
  • Настроим .gitlab-ci.yml
  • Добавим env переменные для CI

Установка зависимостей

Для начала нужно установить pvm, также учесть момент с использованием conventional commit на этом этапе.

Конфигурирование package.json

Pvm использует формат yarn workspaces для определения списка пакетов с которыми он будет работать.

Пример:

{
  "name": "test-mono-repo",
  "workspaces": {
    "packages": [
      "packages/*"
    ]
  }
}

Здесь мы указали, что в нашей монорепе пакеты расположены в директории packages.

Конфигурация pvm

Теперь нам нужно сконфигурировать pvm, для этого в корне репозитория создаем файл .pvm.toml, в котором мы будем указывать кастомные параметры нашего проекта.

[update]
dependants_release_type = 'as-dep'

# Конфигурация нотификаций при релизах библиотек
[notifications.clients_common_config]
channel = '#temp'
author = { name = 'pvm minion', avatarEmoji = ':deciduous_tree:' }

Помимо прочего мы здесь задали опцию dependants_release_type и теперь у нас при изменении пакетов, все пакеты, которые зависели от первых, будут наследовать тип релиза. По умолчанию зависимые пакеты имеют тип релиза patch.

Полное описание всех дефолтных параметров, можно найти в файлах pvm-defaults.ts и config-schema.ts.

Конфигурация .gitlab-ci.yml

Мы будем запускать pvm в CI и при каждом мердже в master будет делать автоматический релиз библиотек, которые изменились.

В данном случае мы реализуем flow с релизным коммитом, про который мы говорили в предыдущей части главы.

Напомню что выглядит он так: мы мержим новые коммиты в master, отрабатывает Pipeline, который определяет какие пакеты обновились и делает новый релизный коммит c тегом. Дальше на этот релизный тег тригерится команда публикации и артефакты заливаются в npm.

Пример конфигурации:

image: node:14.15.0

stages:
  - install
  - update
  - test
  - publish

# Добавляем для MR лейблы и комментарии с графом зависимостей и ченджлогом
mark merge request:
  stage: update
  interruptible: true
  except:
    - master
    - tags
  script:
    - yarn pvm mark-pr

# Создаем релизный коммит с измененными зависимостями
update:
  stage: update
  only:
    - master
  except:
    refs:
      - tags
    variables:
      - $CI_COMMIT_MESSAGE =~ /^Release/i
  script:
    - yarn pvm update

# Тригерется на релизные коммиты и заливает данные в npm
publish npm:
  stage: publish
  only:
    refs: 
      - /^release-/
      - /^v\d+\.\d+\.\d+/
  except:
    - branches
  script:
    # паблишит только те пакеты, версии которых были обновлены
    # в последнем релизном коммите
    - yarn pvm publish

# Команда "на всякий случай",
# которая позволяет синхронизировать данные между репозиторием и npm
manual republish:
  stage: publish
  only:
    - master
  when: manual
  script:
    - yarn pvm publish -s stale

# проверка корректности версий в пакетах
# в целом команда не обязательна
lint:
  stage: test
  except:
    - master
    - tags
  script:
    - yarn pvm lint

ENV переменные в CI

Для работы PVM мы должны объявить ENV переменные в CI

Опциональные переменные

  • npm_config__auth и другие env переменные для npm – можно указать если вы используете простую авторизацию в npm.
  • GIT_SSH_PRIV_KEY – обязательна в случае использования гитлаба и если выставлена настройка update.commit_via_platform в false. Подробнее про настройку можно почитать здесь.
  • SLACK_TOKEN или SLACK_WEBHOOK_URL (deprecated) – токен или урл для слак-нотификаций, при необходимости. Также поддерживаются переменные с тем же именем, но префиксом PVM_. Лучше использовать токен, вебхуки слака это deprecated решение.

Итоги

Это законченный, и даже местами избыточный пример того, как можно реализовать версионирование и доставку пакетов через CI/CD гитлаба.