Блог

После клонирования репозитория в файле gitlab ci yml я хочу получить доступ к файлу из клонированного репозитория, как в следующем коде

файл gitlab-ci.yml

 include:  - project: my-project  ref: mybranch  file: file1.yml  before_script:  - echo "Before script setup"  - git clone -b mybranch --single-branch my-project.git  

Теперь в файл1.yml моего проекта я хочу включить файл

файл1.yml

 include:  local: ./my-project/template/common.yml  

это говорит о том, что локальный файл не существует

Включает в себя просто, они просто вставляют содержимое файла, который вы включаете, в ваш текущий файл GitLab CI.

в вашем случае это будет выглядеть так:

 include:  local: ./my-project/template/common.yml  before_script:  - echo "Before script setup"  - git clone -b mybranch --single-branch my-project.git  

и у вас нет этого файла в вашем локальном хранилище.

Решение

Поскольку вы можете включить файл только один раз, я рекомендую не использовать включение на нескольких уровнях. Что делать, если у вас есть file2.yml то, что также включает common.yml в себя — и вам нужно и то, и другое? это также приведет к ошибке. Я предлагаю пойти по условному пути и заставить людей всегда включать common.yml , если они также включают другой файл из вашего шаблонного проекта

В вашем случае, если вы говорите только об одном проекте , вам не нужно иметь такую причудливую структуру включения с project , ref и file . Достаточно воспользоваться local директивой. Нравится

 include:  - local: file1.yml  

то же самое касается включения в файл. Я не уверен, что my-project в вашем случае, я предполагаю, что это тот же репозиторий. Чем вам не нужно заботиться git clone , это будет сделано автоматически заданием GitLab CI, и все файлы будут доступны в одном каталоге.

шаблон проекта

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

 include:  - project: templateproject  ref: mybranch  file:  - common.yml  - file1.yml  

Если ваши общие.yml-это триггеры, просто назовите его триггерами и попробуйте разделить функциональность на отдельные файлы. Я обнаружил, что хорошей практикой является предоставление нескольких строительных блоков, и пусть сами проекты объединяют их — с одним значением по умолчанию, на которое можно взглянуть.

Мы предоставляем отдельные услуги для:

• раздражители
• блоки сценариев
• служебные методы, такие как вход в систему docker и т. Д.

проекты никогда не получат полностью законченную работу (за исключением инструментов безопасности и качества), но должны организовать их следующим образом:

 include:  - project: templates  file:  - triggers.yml  - script.yml  job1:  stage: build  extends:  - .trigger # a job named like this in triggers.yml which contains rules  - .build # a job named like this in script.yml for building  job2:  stage: test  extends:  - .trigger # a job named like this in triggers.yml which contains rules  - .test # a job named like this in script.yml for building  

Таким образом, проект содержит не только include, но и дополнительную информацию о сборке, и вы можете представить, что происходит, посмотрев файл CI. Здесь мало косвенных указаний, и до тех пор, пока вы сохраняете имена простыми и описательными, вы можете повысить читаемость.