2014-02-03 3 views
53

У меня есть работа под названием «разработка» и еще один проект под названием «анализ кода». На данный момент у нас есть две разные рабочие места и разные рабочие пространства, но один и тот же код; есть ли способ использовать одно и то же рабочее пространство для нескольких заданий?
Я проверил плагины, доступные в Дженкинсе, но я не нашел подходящего.То же рабочее пространство для нескольких заданий

+3

вы можете использовать специальное рабочее пространство http://stackoverflow.com/questions/20537137/custom-workspace-in-jenkins – KeepCalmAndCarryOn

+4

Если вы используете одно и то же рабочее пространство, вы захотите убедиться, что у вас нет параллелизма, и что вы можете правильно отслеживать изменения между ними. Параллелизм может произойти, если вы находитесь в процессе анализа кода, когда задание на разработку начинает проверять код. Существуют плагины (и ответы) о том, как предотвратить проблемы на этом сайте. (Полное раскрытие: мы попробовали общее рабочее пространство и решили, что нам лучше работать с плагином рабочей области клонирования с отдельными рабочими областями.) – jwernerny

+1

Чтобы сделать этот параллелизм легко, запускайте задачу анализа из задания разработки и проверьте расширенный вариант проекта " Блочная сборка, когда проект восходящего потока строится "на задаче анализа. –

ответ

62

Предположим, что ваше рабочее место для работы Jenkins - /var/workspace/job1. На странице задания code analysis в разделе Advanced Project Options нажмите Advanced и выберите опцию Use custom workspace и укажите ту же рабочую область /var/workspace/job1 с вашей разработкой.

+19

Это достойный путь ... но я бы взял его на один шаг ближе и использовал https://wiki.jenkins-ci.org/display/JENKINS/inheritance-plugin для наследования $ {WORKSPACE}, поэтому он не " t должны быть жестко закодированы на всех рабочих местах - он будет более чистым для обслуживания. – thekbb

+5

@thekbb, это будет вариант, за исключением переполнения стека, который возникает при использовании в сочетании с плагином JobConfigHistory. Пока сопровождающий не исправляет эту проблему, это бесполезно для любого, кому нужен плагин JobConfigHistory для заданий, которые * не используют наследование ... –

+0

Каталоги рабочей области различаются между мастером (job//workspace) и подчиненными узлами (рабочее пространство/.Таким образом, жесткий код включает в себя скрипт и плагин. – rickfoosusa

4

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

Use Case:

Подобно тому, что вам нужно сначала создать два задания из той же Git репозиторий, а затем перейти к «Управление Дженкинс» и вы создаете Shared Workspace. И укажите на это, на каждом задании, которое вам нужно прочитать из этих файлов.

Дженкинс Плагин

https://wiki.jenkins-ci.org/display/JENKINS/Shared+workspace+plugin#


PS: Вы должны смотреть на "Известные проблемы" может быть дело выключатель для ваших нужд.

Иногда, при свежей скопированной задаче, параметр url общего пространства не сохраняется в конфигурации при первом «сохранении», вы должны сохранить работу дважды, чтобы быть уверенным.

^^ Это одно это все-таки нерешенным, я пытался и до сих пор происходит. После нескольких сбережений (просто чтобы убедиться) работа работает отлично.

1

, если вы не смогли найти Use custom workspace вы можете находитесь под ваш проект configure>General>Advanced>Use custom workspace

Смежные вопросы