Я использую Gitlab CI для своего проекта. Когда я нажимаю на ветку разработки, она запускает тесты и обновляет код в моей тестовой среде (удаленном сервере).
Но бегун gitlab уже использует ту же папку сборки: builds/a3ac64e9/0/myproject/myproject
Но я бы хотел каждый раз создавать папку now:
builds/a3ac64e9/1/yproject/myproject
builds/a3ac64e9/2/yproject/myproject
builds/a3ac64e9/3/yproject/myproject
Используя это, я мог просто обновить свой веб-сайт, изменив символическую ссылку, указывающую на последний каталог бегуна.
Есть ли способ настроить Gitlab Runner таким образом?
Вы не можете добиться этого только с помощью конфигурации Gitlab CI runner, но вы можете создать 2 runner'а и назначить их исключительно каждой ветке, используя комбинацию ключевых слов only
и tags
.
Предположим, что ваши две ветки названы master
и develop
, а два бегуна помечены тегами master_runner
и develop_runner
, ваш .gitlab-ci.yml
может выглядеть следующим образом:
master_job:
<<: *your_job
only:
- master
tags:
- master_runner
develop_job:
<<: *your_job
only:
- develop
tags:
- develop_runner
(<<: *your_job
- это ваша настоящая работа, которую вы можете разложить на множители)
Возможно, вы захотите прочитать следующий ответ Изменение промежуточных путей сборки для gitlab-runner
Я отправлю свой ответ здесь:
С концептуальной точки зрения, такой подход не подходит; каталог сборки не является каталогом развертывания, это временный каталог для сборки или развертывания из, тогда как в исполнителе оболочки это можно исправить.
Итак, вам нужно выполнить развертывание из этого каталога с помощью сценария согласно gitlab-ci.yml
ниже в правильный каталог развертывания.
stages:
- deploy
variables:
TARGET_DIR: /home/ab12/public_html/$CI_PROJECT_NAME
deploy:
stage: deploy
script:
mkdir -pv $TARGET_DIR
rsync -r --delete ./ $TARGET_DIR
tags:
- myrunner
Это переместит ваш projectfiles
в / home / ab12 / public_html /
Называя свои проекты project1
.. projectn
, все ваши проекты могут использовать один и тот же файл .gitlab-ci.yml
.
Хотя нет смысла использовать каталог сборки в качестве каталога развертывания, вы можете настроить собственный каталог сборки.
Откройте config.toml в текстовом редакторе: (подробнее о том, где его найти здесь)
Установите enabled = true
под [runners.custom_build_dir]
(подробнее здесь)
[runners.custom_build_dir]
enabled = true
В вашем файле .gitlab-ci.yml в разделе variables
установите GIT_CLONE_PATH
. Он должен начинаться с $CI_BUILDS_DIR/
, например $CI_BUILDS_DIR/$CI_JOB_ID/$CI_PROJECT_NAME
, который, вероятно, даст вам то, что вы ищете, хотя, если у вас несколько этапов, у них будут разные идентификаторы вакансий. В качестве альтернативы вы можете попробовать $CI_BUILDS_DIR/$CI_COMMIT_SHA
, который предоставит вам уникальную папку для каждой фиксации. (Подробнее здесь)
variables:
GIT_CLONE_PATH: '$CI_BUILDS_DIR/$CI_JOB_ID/$CI_PROJECT_NAME'
Unfortunately there is currently an issue with using
GIT_BUILDS_DIR
inGIT_CLONE_PATH
, if you're using Windows and Powershell, so you may have to do something like this as a work-around, if all your runners have the same build directory:GIT_CLONE_PATH: 'C:\GitLab-Runner/builds/$CI_JOB_ID/$CI_PROJECT_NAME'
Вы можете взглянуть на доступные вам переменные (предопределенные переменные), чтобы найти наиболее подходящие переменные для вашего пути.
Согласно docs.gitlab.com/runner/configuration/… вы не можете