Как помешать Дженкинсу получить все рабочее пространство TFS? - PullRequest
1 голос
/ 12 марта 2020

Я пытаюсь построить один проект в том, что по сути является монорепо.

Используя плагин TFS в Jenkins, я установил путь к проекту для указанного c проекта, который я хочу построить, и установил локальная рабочая папка в расширенных настройках соответственно. Таким образом, я мог получить все зависимости проекта от monorepo, которые мне нужны для создания этого одного проекта, используя скрипт внутри Jenkinsfile. По крайней мере, я так думал.

Как только я сопоставил рабочую область Jenkins с репозиторием root, Дженкинс, похоже, получает весь репозиторий при сборке, который в итоге завершается неудачей с исключением из-за нехватки памяти, полностью игнорируя то, что я установил в «Путь к проекту».

Но даже если это не сработает, на самом деле c идея не будет иметь полную копию всего репо для каждого проекта, который мы хотим построить .

Как это можно решить? Прекратить использование плагина TFS и, возможно, все операции TFS в Jenkinsfile?

1 Ответ

1 голос
/ 13 марта 2020

Предположим, у вас есть $/Repo/project и $/Repo/dependency. Вам просто нужно вытащить их обоих в Дженкинс для одной сборки. Естественно, вы пробовали $/Repo root, но это дало вам кучу других проектов вместе с

Полностью игнорируя то, что я установил в «Путь к проекту». Вы можете использовать путь к нескольким проектам.

Подключаемый модуль TFS для Jenkins в настоящее время не поддерживает извлечение источников из нескольких мест .

Как решение, так же как Ian W указал, что у вас есть возможность скрывать папки в вашем $ \ Repo, которые вам не интересны. При проверке скрытых папок сборка не будет запускаться. К сожалению, согласно вашему комментарию, в нем может быть много папок.

Другое решение - создать несколько заданий, некоторые из которых просто загружают вашу зависимость, а другие - для сборки.

Например, создайте три задания в Jenkins, каждое из которых «вниз по течению» от другого:

Попытка сборки использует $ / Repo / project (как рабочее пространство \ TheProgram) и $ / Repo / dependency (как рабочее пространство \ Framework).

  • Framework-Get: нормальный запуск исходного кода на пути проекта TFS $/Repo/project. Нет шага сборки.
  • TheProgram-Get: нормальный запуск исходного кода по TFS 'Product Path of $/Repo/dependency. Нет шага сборки.
  • TheProgram-Build: Нет контроля исходного кода. Но этапы сборки xcopy - источник двух вышеупомянутых шагов. Затем вы можете выполнить обычный шаг сборки.

Первый шаг сборки TheProgram-Build - это windows пакетная команда:

REM ==================================== REM First Get the
Framework folder: rmdir /s/q Framework mkdir Framework xcopy /y /q /e
..\..\Framework-Get\Workspace\Framework Framework

REM ==================================== REM Then Get the TheProgram
Folder: rmdir /s/q TheProgram  mkdir TheProgram  xcopy /y /q /e
..\..\TheProgram-Get\Workspace\TheProgram TheProgram 

Второй шаг сборки был простым вызовом для сборки используйте msbuild или что-нибудь еще здесь.

Вы также можете объединить job1 и job3 вместе, чтобы упростить ваш рабочий процесс, который фактически требует только двух заданий.

...