Зафиксировать файл из рабочей области Jenkins в SVN

можете ли вы дать немного больше деталей? Что именно это за файл, и почему он должен быть зафиксирован как часть вашей сборки Jenkins? Что вы строите (Java? C++? .NET?) и как вы его строите?

обычно вы не должны ничего помещать под контроль версий, кроме источник файлы. То есть, если вы можете его построить, Вы не должны помещать его в управление версиями. Многие люди любят фиксировать свой встроенный код в свою систему управления версиями, но обычно это самая большая ошибка. двоичные файлы намного больше и редко отличаются. Это приводит к исходному репозиторию, который на 90% скомпилирован, - почти весь он устарел. Это особенно проблематично с Subversion, у которого нет способа (легко) удалить устаревший код.

Дженкинс имеет функцию, которая позволяет архиве ваши встроенные файлы для легкого доступа. Мы используем это все время. Мы строим наш код, и программа доступна в Jenkins для загрузки. Даже лучше, Дженкинс будет удалите старые сборки (вы можете сохранить последние сборки X или сохранить только сборки моложе X дней). И если у вас есть сборка кандидата на выпуск, вы можете замок эта сборка, чтобы предотвратить ее удаление.

тем не менее, если вы настаиваете на этом, есть несколько вещей, которые вы можете сделать, и вы должны следить за:

1. когда у вас есть Jenkins setup для автоматического создания каждого изменения, и вы фиксируете изменение в своем элементе управления версиями система, Дженкинс увидит это и начнет новую сборку. Затем Дженкинс сохраняет изменение, видит изменение и выполняет другую сборку. Убедитесь, что вы исключаете файлы или каталоги из рассмотрения Дженкинса, когда он должен выполнить сборку. Это можно указать при указании URL-адреса оформления заказа.

2. В отличие от большинства систем управления версиями, Subversion была сделана независимой от клиента. Существует API для клиентов. Стандартный клиент командной строки Subversion не необходимо в Jenkins, поэтому убедитесь, что он установлен. Убедитесь, что вы установили клиент, совместимый со встроенным клиентом SVNKit Jenkins. Это особенно верно, поскольку Subversion 1.6, 1.7 и 1.8 имеют другой формат клиента.

3. вы можете добавить несколько этапы построения для построения в Jenkins. Просто добавьте новый сценарий оболочки или шаг пакетного сценария и добавьте svn commit -m "comment of some sort" шаг. Это довольно просто сделать, как только вы позаботились о первых двух пунктах. Однако, пожалуйста, подумайте хорошенько, зачем вы это делаете.

Как я уже говорил, 99.9999% времени, вы не должны использовать Дженкинса для фиксации изменений, которые он построил. Я уверен, что причина 0.0001% существует где-то, но я никогда не видел его. Если вы хотите сделать встроенные файлы универсально доступными для других ваших проектов, используйте способность Дженкина архивировать встроенные файлы.

Если продукт, который создает Дженкинс, необходим для другой сборки, вы можете использовать Копировать Артефакт Плагин скопировать артефакт сборки в другое задание, а затем запустить это задание. Еще лучше использовать систему репозитория release. В Java вы можете использовать репозиторий выпуска Maven, такой как Nexus или Artifactory. Для использования и развертывания артефактов в этом репозитории можно использовать Ivy, Maven или Gradle. Если вы создаете .NET, посмотрите на Nuget.