Возможно ли иметь в BuildBot более одного шага проверки исходного кода?

Возможно ли иметь в BuildBot более одного шага проверки исходного кода? Я не могу найти какой-либо явной документации по этому поводу, но похоже, что при извлечении исходного кода в BuildBot также изменяется текущий рабочий каталог на каталог извлечения, что означает, что неясно, куда можно «перейти» для извлечения из другого репозитория, а затем запустить сценарий, который использует оба.

Рассмотрим пример на http://buildbot.net/buildbot/docs/0.8.1/BuildFactory.html:

Судя по шагам, выполняется проверка CVS, а затем запускается make build. Это два шага в BuildBot, что удобно.

Однако, если бы вы делали то же самое из командной строки, это было бы три шага:

cvs co $CVSROOT
cd directory_that_was_created
make build

Где происходит шаг cd directory_that_was_created в BuildBot?

Но что более важно, что, если я хочу иметь два source.CVS (ну, на самом деле source.Git) шагов? В каком каталоге я нахожусь после выполнения второго шага? Второй репо попадает в подкаталог первого репо?

С Git кажется, что я мог бы сделать один подмодуль другого, чтобы гарантировать, что они оба будут проверены за один шаг, хотя я бы предпочел не делать этого, если это возможно.


buildbot
person bolinfest    schedule 26.08.2012    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Хорошо, я понял это. Я не понимал, что существует концепция «рабочего каталога», связанная с каждым шагом, которая указывает, где происходит «работа». По умолчанию workdir для всех шагов — это каталог с именем build.

На http://buildbot.net/buildbot/docs/latest/manual/cfg-buildsteps.html в разделе Проверка исходного кода -> Общие параметры -> workdir, признает, что исходные шаги являются особыми " в том, что они выполняют некоторые операции вне рабочего каталога (например, создают сам рабочий каталог)».

Это объясняет, почему в приведенном выше примере нет явного шага, соответствующего команде cd. Чтобы решить мою проблему, я создал два шага Git, каждый со своим собственным значением workdir. За этим следуют последующие ShellCommand шаги, которые обращаются к соответствующему каталогу, зная, что два workdir каталога будут родственными друг другу.

person bolinfest    schedule 27.08.2012
comment
На самом деле это не работает, если вы используете планировщик, который запускается в ответ на конкретный хэш коммита. В этом случае оба шага Git пытаются получить один и тот же хэш, который существует в одном репо, но не существует в другом. Вместо этого я запустил git clone в ShellCommand. Если бы в Git можно было указать, что всегда получать из головы, независимо от того, что говорит планировщик, то мне не пришлось бы этого делать. - person bolinfest; 31.08.2012
comment
этой проблемы можно избежать, указав alwaysUseLatest=True на шаге сборки вторичного репозитория, избегая попытки использовать sourceStamp других репозиториев. - person alanc10n; 16.11.2016