Jenkins не проверяет все файлы от Starteam

Question

Я экспериментирую с установкой 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 ничего не раскрывает. Я не знаю, есть ли какой-то режим отладки, который я мог бы использовать, чтобы отслеживать характер проблемы?

Возможно, я должен добавить, что в настоящее время Дженкинс работает локально на моем ПК (Win7), пока я экспериментирую с настройкой. Я использую расположение по умолчанию c: \ Program Files (x86) \ Jenkins \ Jobs \ JOB_NAME \ Workspace для интеграции моего решения.

Я надеюсь, что некоторые из вас, ребята, могут подумать о том, в чем проблема, так как мне бы хотелось, чтобы у меня была улучшенная настройка CI, чем у нас в настоящее время.

Answer 1

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

Я смог проверить это, удалив файл в исходном местоположении (т. Е. НЕ в папке заданий Jenkins), а затем наблюдайте, как файлы снова появлялись в исходном местоположении во время проверки Jenkins. Что действительно побудило меня исследовать это дальше, так это попробовать проверить файлы из StarTeam с помощью утилиты cmd-line, чтобы проверить файлы в другом месте. Когда это все еще не получило все проверенные файлы, я предположил, что Дженкинс больше не виноват, но вместо этого что-то не так.

Причина, по которой я не заметил этого раньше, частично объясняется моим небольшим опытом работы с StarTeam и всеми разработчиками нашей команды, использующими те же сопоставления и пути в нашей среде разработки.Следовательно, абсолютный путь помещал файл в нужное место на всех машинах, потому что используемые пути были идентичными.

Answer 2

По сути, SDK StarTeam обрабатывает проверку файлов при интеграции с любым внешним приложением. Создание клиента 10.4, которое вы используете, выглядит совершенно устаревшим, поэтому я рекомендую обновить сборку SDK, если не весь клиент.

StarTeam имеет относительно хорошую совместимость в обратном/обратном направлении, когда дело доходит до клиента/SDK, поэтому вы можете теоретически запустить SDK 2009/2009R2 против существующей установки клиента 2008 R2.

Что касается режима отладки в Дженкинс, вы можете активировать это в командной строке, выполнив следующий синтаксис:

java -Drally.debug="true" -jar jenkins.war --httpPort=9000