Как указать файл buildspe c, содержащийся во вторичном источнике в Codebuild? - PullRequest
0 голосов
/ 30 мая 2020

Я планирую создать проект сборки с двумя источниками:

Первичный источник - это репозиторий приложения, которое я создаю.

Вторичный источник - это репозиторий, содержащий общие c buildspe c .yml и другие файлы, такие как конфигурации eslint.

Причина в том, что я хочу отделить код приложения от определения сборки, чтобы я мог повторно использовать одно и то же определение сборки для нескольких приложений. Тот же buildspe c .yml и сопутствующие файлы eslint подходят для сборки любых моих серверных приложений.

Согласно документации путь buildspe c для проекта сборки является путем относительно root путь первоисточника.

Но как правильно указать на buildspe c .yml, находящийся во вторичном источнике?

(Насколько я знаю, код приложения должен быть основным источником, чтобы Codebuild мог обнаруживать изменения кода, такие как открытые PR и кодировать операции pu sh.)

(я знаю, что Codebuild допускает путь S3 как buildspe c путь, но я не вижу, как это может мне помочь, так как мой вторичный источник - репозиторий.)

Спасибо!

1 Ответ

1 голос
/ 02 июня 2020

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

Когда вы создаете проект сборки, вы должны определить buildspe c, который будет использоваться . Ваш проект сборки будет использовать buildspe c из вашего ПЕРВИЧНОГО источника. Таким образом, ИСТОЧНИК, имеющий ваш основной buildspe c, должен быть вашим PRIMARY, а проект, который вы собираетесь построить, будет вашим SECONDARY.

Затем в вашем buildspe c вы можете ссылаться на команды, указывающие в ваш ВТОРИЧНЫЙ источник, используя переменные среды. В вашем buildspe c вы должны ссылаться на CODEBUILD_SRC_DIR_sourceIdentier.

Я сделал это с помощью codepipeline, имеющего несколько источников. Если вы определяете свой вывод для вторичного источника как SECONDARY_SOURCE_OUTPUT

source output naming example

, тогда вы должны ссылаться на него в своем buildspe c как на $ CODEBUILD_SRC_DIR_SECONDARY_SOURCE_OUTPUT / .

Ваша buildspe c существует в вашем основном источнике, но вы должны установить, что ваши команды будут выполняться из каталога выше в вашем buildspe c. Теперь у вас может быть несколько похожих проектов с одним и тем же шаблоном сборки, использующих один и тот же buildspe c.

В приведенном ниже случае я использую тот же buildspe c из проекта слева на стадии исходного кода. , с различными проектами, которые можно использовать в качестве вторичных источников.

what a codepipeline would look like.

Эта ссылка содержит некоторую информацию о нескольких источниках.

...