Зафиксировать файл из рабочей области Jenkins в SVN
У меня есть сохраненный проект в хранилище Subversion и скомпилирован с Дженкинсом. Когда я запускаю сборку, Дженкинс тянет проект в каталог рабочей области. Мне нужно зафиксировать один измененный файл из рабочей области Jenkins в Subversion. Как мне это сделать??
Спасибо за ответы...
3 ответа
Можете ли вы дать еще несколько деталей? Что это за файл, и почему он должен быть зафиксирован как часть вашей сборки Jenkins? Что вы строите (Java? C++? .NET?) И как вы это делаете?
Обычно вы не должны ставить под контроль версии ничего, кроме исходных файлов. То есть, если вы можете построить его, вы не должны помещать его в систему контроля версий. Многие люди любят вносить свой встроенный код в свою систему контроля версий, но обычно это большая ошибка. бинарные файлы намного больше и редко различаются. В результате получается исходный репозиторий, который на 90% скомпилирован, почти все устарело. Это особенно проблематично с Subversion, который не имеет способа (легко) удалить устаревший код.
Jenkins имеет функцию, которая позволяет архивировать ваши встроенные файлы для быстрого доступа. Мы используем это все время. Мы создаем наш код, и программа доступна в Jenkins для загрузки. Более того, Jenkins удалит более старые сборки (вы можете сохранить последние сборки X или сохранить только сборки моложе X дней). И если у вас есть сборка кандидата на выпуск, вы можете заблокировать эту сборку, чтобы предотвратить ее удаление.
Тем не менее, если вы настаиваете на этом, есть несколько вещей, которые вы можете сделать, и вещи, которые вы должны остерегаться:
Если у вас есть настройка Jenkins для автоматической сборки каждого изменения, и вы фиксируете изменение в своей системе контроля версий, Jenkins увидит это и начнет новую сборку. Затем Дженкинс сохраняет изменения, видит изменения и выполняет другую сборку. Убедитесь, что вы исключили файлы или каталоги из рассмотрения Jenkins, когда он должен выполнить сборку. Вы можете указать это при указании URL-адреса оформления заказа.
В отличие от большинства систем контроля версий, Subversion была сделана независимой от клиентов. Существует актуальный API для клиентов. Стандартный клиент Subversion для командной строки не нужен в Jenkins, поэтому убедитесь, что он установлен. Убедитесь, что вы установили клиент, совместимый со встроенным в SVNKit клиентом Jenkins. Это особенно верно, поскольку Subversion 1.6, 1.7 и 1.8 все используют другой формат клиента.
Вы можете добавить несколько шагов для сборки в Jenkins. Просто добавьте новый сценарий оболочки или шаг пакетного сценария и добавьте в
svn commit -m "comment of some sort"шаг. Это довольно просто сделать, если вы позаботились о первых двух пунктах. Однако, пожалуйста, подумайте, почему вы это делаете.
Как я уже говорил, в 99,9999% случаев вам не следует использовать Jenkins для фиксации созданных изменений. Я уверен, что причина в 0,0001% существует где-то, но я никогда не видел ее. Если вы хотите сделать встроенные файлы универсально доступными для других ваших проектов, используйте возможность Jenkin для архивирования встроенных файлов.
Если продукт, созданный Jenkins, необходим для другой сборки, вы можете использовать плагин Copy Artifact, чтобы скопировать артефакт сборки в другое задание, а затем запустить его. Еще лучше использовать систему репозитория релизов. В Java вы можете использовать репозиторий релизов Maven, например Nexus или Artifactory. Чтобы использовать и развертывать артефакты в этом хранилище, вы можете использовать Ivy, Maven или Gradle. Если вы создаете.NET, посмотрите на Nuget.
Посмотрите, пожалуйста, на этот ответ: Jenkins svn commit post-build
Должна быть возможность выполнить фиксацию с новым шагом сборки (или шагом после сборки).
Но будьте осторожны с SVN-макетом рабочего пространства Jenkins. Плагин Subversion использует SVNKit для работы с командами SVN. Ваше рабочее пространство может использовать формат SVN 1.6.
Если на вашем компьютере установлен более поздний SVN-клиент, ваша фиксация SVN завершится неудачно со следующей ошибкой: org.apache.subversion.javahl.ClientException: необходимо обновить рабочую копию svn: Рабочая копия 'C:.... is слишком старый (формат 10, созданный Subversion 1.6)
Вы могли бы тщательно использовать:
svn commit -username someuser -password %injected_password%
ввести пароль в Build Environmentэта команда вводит пароли в сборку как переменные среды
Остерегайтесь: этот пароль может быть виден в пакете триггера задания.