Как опубликовать пакет NPM из конвейера сборки CI и при этом автоматизировать управление версиями? - PullRequest
Новая
       61

Как опубликовать пакет NPM из конвейера сборки CI и при этом автоматизировать управление версиями?

5 голосов
/ 20 сентября 2019

Кажется, я не вижу леса за деревьями.Я хочу иметь простой конвейер CI, который собирает и публикует пакет NPM.Я использую appveyor, но я не думаю, что моя проблема связана с этим.Я просто хочу, чтобы мой скрипт CI выполнял что-то вроде этого: 

git clone "https://git_repo_url" .
npm run build
npm run test
npm version patch --git-tag-version
npm publish -tag beta

Проблема в следующем:

  • Если я не выполню шаг npm version patch,публикация завершится с ошибкой feed already contains the package 'abc' at version 'x.y.z'.

  • Если я сделаю этот шаг, то мне придется перенести новый коммит (изменение версии) обратно в репозиторий git.В противном случае он потерпит неудачу, как описано выше в следующий раз, когда я или кто-то еще построим его.Однако я не думаю, что выполнение git push в фоновом конвейере было бы правильным.

  • Наконец, если этот сценарий CI просто создает пакет NPM без его публикации,как использовать его в других проектах, которые зависят от него?

Каковы стандартные для отрасли способы сделать это?

Например, , если мне нужно протестировать непроизводственную функциональную версию моего пакета с другим проектом, должен ли я сделать свой CI-скрипт для исправления пакета package.json сгенерированной, уникальной полу-совместимой версией (без ее фиксации), а затем опубликоватьэто с тегом npm, который будет соответствовать моему имени в git-ветке?Это хорошая идея?

Ответы [ 3 ]

5 голосов
/ 21 сентября 2019

Отвечаю сам.Как предложено в комментарии выше, я решил принять semantic-release для публикации из master ветви.

Для построения и публикации из При разработке веток я создал собственный скрипт для узла, чтобы сгенерировать полуверси-совместимую предварительную версию на основе хэша git commit, текущей версии major.minor.patch и текущего времени: 

const cp = require('child_process');
// get current semver version without prerelease suffix
const pkg = require('./package.json');
const curVer = pkg.version.trim().split(/[.-]/).slice(0, 3).join('.');
// get the commit id
const commit = cp.execSync('git rev-parse --short HEAD', {encoding: 'utf-8'}).trim();
console.log(`Package: ${pkg.name}, version: ${curVer}, commit: ${commit}`);
// generate a new unique semver-compliant version based the commit it and current time
const uniqueVer = `${curVer}-beta-${commit}-${Math.random().toFixed(8).substr(2)}.${Date.now()}`
// use npm version to update package.json
cp.execSync(`npm version ${uniqueVer} --no-git-tag-version`, {stdio: 'inherit'});
// publish and tag with commit id
cp.execSync(`npm publish --tag ${commit}`, {stdio: 'inherit'});

Таким образом, я могу зарегистрировать свои вещи в моей ветке разработчика, собрать конвейер CI и опубликовать пакет для меня, а затем использовать его с npm install mypackage@commitid.Псевдо-уникальная версия будет сгенерирована и опубликована в реестре NPM, но измененный package.json не будет зарегистрирован.

Этот подход должен работать для меня сейчас, но Я бы все равнобыть очень заинтересованным в том, чтобы узнать о лучших практиках DevOps для публикации внутренних / выпусковых пакетов NPM с CI во время обычного цикла разработки .

2 голосов
/ 26 сентября 2019

Я сделал это, как показано ниже, в моем проекте JavaScript.

Примечание: получите форму ключа .npmrc 

publish:
    image: <your project image>
    stage: publish
    script:
        - echo _auth=$NPM_PUBLSH_KEY >> .npmrc
        - echo email=<youremail> >> .npmrc
        - echo always-auth=true >> .npmrc
        # - cat .npmrc
        - npm version --no-git-tag-version $(npm view <yourProject>@latest version)
        - npm version --no-git-tag-version prerelease
        - npm publish
    dependencies:
        - build


build:
    image: <your project image>
    stage: build
    script:
        - node --version
        - npm --version
        - npm ci
        - npm run build -- --watch=false
        - npm run build:prod
1 голос
/ 28 сентября 2019

Мне все равно было бы очень интересно узнать о лучших практиках DevOps для публикации внутренних / выпусковых пакетов NPM с CI во время обычного цикла разработки.

обычно сопровождающий проекта изменяет версию, основываясь на возможностях и \ или изменениях, внесенных в проект.

, например:

  • , если изменения являются критическими (несовместимость с обратными словами), сопровождающий поднимет Major версию
  • , если изменения будут новыми функциями (вспомогательные функции, рефакторинг и т. д.), сопровождающий поднимет minor версия

существует множество подходов для версии patch .здесь 2:

  1. git pre-push hook, который удваивает число patch и фиксирует его в репозитории, что устраняет систему build \ ci, изменяющую исходный код проекта
  2. использовать номер сборки в системе build \ ci в качестве номера patch , игнорируя версию patch , зафиксированную дляхранилище
...