Дженкинс сбрасывает письмо из файловых путей
У нас есть проект Code Composer Studio (Eclipse), который использует CMAKE для генерации make-файлов и сборки. Проект компилируется, как и ожидалось, когда проект вручную импортируется в подчиненное устройство Jenkins (Win10 x64) и выполняется из командной строки, но завершается неудачно, когда сборка обрабатывается Jenkins. Ошибка всегда следует одной и той же схеме: исключительная буква удаляется из пути объектного файла. Например, [Repo directory]/Cockpit_Scaling_and_Exceedance_data.dir
становится [Repo direcory]/Cockpit_Scaling_and_Exceedance_ata.dir
и связывание не удается, потому что он не может найти указанный объектный файл.
Я удостоверился, что нет никаких различий между переменными среды учетной записи и системными переменными среды, а также настроил службу Jenkins для использования учетной записи администратора на ведомом устройстве вместо SYSTEM, чтобы избавиться от стольких различий между Jenkins и командой линия как можно.
Проект будет успешно построен с использованием одного из наших других подчиненных Jenkins (также Win10 x64), поэтому мы знаем, что это не проблема Windows 10 или проблема с нашей конфигурацией Jenkins. Поскольку я не могу найти каких-либо различий между конфигурацией двух подчиненных компьютеров, я надеялся, что кто-нибудь сможет подсказать, где искать эту проблему.
1 ответ
Я так и не узнал, почему пути к объектным файлам были искажены, но мне удалось успешно построить проект на подчиненном устройстве через Jenkins. Все, что я сделал, это изменил все переменные моей системной среды на переменные среды пользователя. Я скопировал-вставил, поэтому знаю, что сами переменные не изменились.
Я понятия не имею, почему это исправило эту проблему, так как я вставил whoami
позвоните в начале сборки, чтобы убедиться, что Jenkins действительно работает как пользователь, а не как System. Я предполагаю, что с этого момента все мои переменные среды будут специфичными для пользователя, а не СИСТЕМЫ...
РЕДАКТИРОВАТЬ: проблема вернулась. Я не добился дальнейшего прогресса в поиске причины этой проблемы, но обнаружил, что не вижу этого симптома при запуске сценариев в среде bash вместо командной строки Windows. К счастью для меня, все сценарии были написаны таким образом, что их можно запускать в обеих средах, поэтому мои коллеги использовали вместо них bash.