Как вы увеличиваете номер версии с помощью Travis CI?

Проект, над которым я работаю, является плагином jQuery. Мне удалось заставить Travis CI создать тестовый проект, успешно используя Gulp/NodeJS. Теперь я пытаюсь определить, какой рабочий процесс использовать, чтобы увеличить номер версии.

В TeamCity и MyGet на CI-сервере есть параметр для формирования шаблона номера версии, который автоматически увеличивается в каждой сборке, который может использоваться сборкой script для обновления версий в файлах развертывания и для маркировки Git repo. Тем не менее, в бесплатной версии Travis CI, похоже, нет возможности для управления версиями.

Я прочитал несколько статей о непрерывном развертывании с Travis CI, здесь, здесь и здесь, но ни один из них даже не затрагивает тему управления версиями. Очевидно, что версия должна быть изменена для выпуска. Так что мне здесь не хватает?

Другая проблема, которую я заметил при просмотре документации, заключается в том, что она упоминает, что Travis CI не может обновить репозиторий GitHub. Разве это не означает, что он не сможет создать тег Git?

Если нет пути к версии из Travis CI, то каков типичный рабочий процесс для процесса выпуска для такого плагина? Выполняется ли управление версиями вручную? Если да, то как может быть "непрерывное развертывание"?

ОТВЕТЫ

Ответ 1

Прежде чем он начнет выполнение инструкций в вашем файле .travis.yml, Travis установит связку переменных (в виртуальной машине, которая строит ваш проект) с различными битами информации о вашей сборке, например, о том, какая ветка строится и т.д.

Возможно, вам понадобится одно из следующих:

  • TRAVIS_BUILD_NUMBER: номер текущей сборки (например, "4" ).
  • TRAVIS_JOB_NUMBER: номер текущего задания (например, "4.1" ).

Но будет очень сложно сделать что-нибудь разумное, если у вас нет контроля над репозиторией, потому что вам нужно будет загрузить файл .travis.yml в корень вашей папки с исходным кодом, иначе Travis выиграет ' Знать, что делать.

Ответ 2

Если вы считаете, что каждый PR должен доходить до вашего конечного пользователя, не задумываясь о влиянии таких изменений, то ваши номера версий не имеют смысла.

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

В настоящее время идентификатор фиксации - это номер вашей версии.

Если вы хотите придать смысл вашим номерам версий, вам нужно подумать о влиянии ваших запросов на тягу на enduser (http://semver.org/). Вы должны выбрать номер версии для определенного PR или группы PR.

В принципе, поскольку вам нужно "думать" о некотором номере версии для определенной версии, которую вы хотите доставить, вы не можете автоматизировать этот процесс.

Создание релиза/метки - путь:)

Ответ 3

Используйте bumped для выпуска версий. Когда вас устраивают изменения в главном, запустите:

bumped release <major|minor|patch>

После того, как вы нажмете изменения, либо напрямую, либо через PR PR-релиза, вы можете проверить наличие новых тегов в Travis CI и автоматически публиковать пакет в реестре.

Ответ 4

Это можно сделать, настроив script, который создаст файл ~/.netrc для доступа к репозиторию. В этом файле вы можете указать что-то вроде:

machine https://github.com/xxx/yyy.git
login <blah>

Вместо того, чтобы вводить ваши учетные данные, вы можете передать токен доступа github. Вы можете использовать travis encrypt для регистрации в файле .travis.yml и экспортировать переменную для использования script. Оттуда в script вы можете выпустить обычные команды git, например:

git add <some file>
git commit -m "This is $TRAVIS_BUILD_NUMBER"
git push origin <branch>