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