Дженкинс не проверяет все файлы из Starteam
Я экспериментирую с настройкой Jenkins, чтобы улучшить нашу стратегию CI, которая в настоящее время состоит из сценария Automated Build Studio, запускаемого планировщиком задач Windows. Исходный код, который я хочу интегрировать, представляет собой решение.NET, которое я пытаюсь создать с помощью MSBuild.
В качестве нашего SCM мы используем StarTeam (v. 10.4), и в настоящее время у меня возникают проблемы, когда Дженкинс пытается извлечь файлы в рабочую область и скомпилировать решение.
Существуют определенные файлы (они всегда одинаковы), которые не извлекаются плагином Jenkins StarTeam. Очевидно, что поскольку эти файлы отсутствуют, я не могу использовать Jenkins для CI. Я не испытываю этой проблемы с нашим скриптом Automated Build Studio: здесь все файлы проверены правильно.
С моей точки зрения, нет ничего особенного в файлах C#, которые не проверяются: они находятся в разных проектах, содержат разные типы данных (некоторые winforms, некоторые интерфейсы), все они являются частью одного и того же представления, похоже, что он был добавлен в StarTeam таким же образом и т. д.
Журнал голосования StarTeam в Jenkins ничего не показывает. Я не знаю, есть ли какой-нибудь режим отладки, который я мог бы использовать, чтобы отследить природу проблемы?
Возможно, я должен добавить, что в настоящее время Jenkins работает локально на моем настольном компьютере (Win7), пока я экспериментирую с настройкой. Я использую местоположение по умолчанию c:\Program Files(x86)\Jenkins\Jobs\JOB_NAME\Workspace для интеграции моего решения.
Я надеюсь, что некоторые из вас, ребята, могли бы иметь представление о том, в чем заключается проблема, так как я действительно хотел бы иметь лучшую настройку CI, чем то, что мы в настоящее время имеем.
2 ответа
I managed to identify the problem: Apparently, one of the developers in our team sometimes manages to change the default location property of folders when adding them to StarTeam. So instead of checking in files with a location relative to the project root, we end up with an absolute path in our repository.
Я смог убедиться в этом, удалив файл в исходном месте (т.е. НЕ в папке заданий Jenkins), а затем наблюдал, как файлы снова появлялись в своем первоначальном месте во время проверки Jenkins. Что действительно побудило меня исследовать это дальше, так это попробовать файлы из StarTeam, используя утилиту cmd-line, чтобы проверить файлы в другом месте. Когда это все еще не проверило все файлы, я предположил, что Дженкинс больше не был виноват, но вместо этого что-то еще было не так.
Причина, по которой я раньше этого не замечал, отчасти связана с моим небольшим опытом работы со StarTeam и с тем, что все разработчики в нашей команде использовали одинаковые отображения и пути в нашей среде разработки. Следовательно, абсолютный путь помещал файл в правильном месте на всех машинах, потому что используемые пути были идентичны.
По сути, StarTeam SDK обрабатывает извлечение файлов при интеграции с любым внешним приложением. Сборка 10.4 клиента, который вы используете, кажется устаревшей, поэтому я бы рекомендовал обновить сборку SDK, если не весь клиент.
StarTeam обладает относительно хорошей совместимостью вперед / назад, когда речь заходит о клиенте /SDK, поэтому теоретически вы можете запустить SDK 2009/2009R2 для существующей установки клиента 2008 R2.
Что касается режима отладки в Jenkins, вы можете активировать его в командной строке, выполнив следующий синтаксис:
java -Drally.debug="true" -jar jenkins.war --httpPort=9000