Как отправить тег в защищенную ветку с помощью GitLab CI?
У меня есть собственный репозиторий GitLab с защищенной веткой разработки. Я хочу, чтобы наша промежуточная среда всегда была синхронизирована с главой ветки разработки. Таким образом, при каждом успешном слиянии с веткой разработки мы создаем тег в GitLab, который запускает другой конвейер для развертывания в нашей промежуточной среде. Эти теги в настоящее время создаются вручную.
У нас много разных проектов, которые используют одни и те же фрагменты скриптов. Из-за совместимости с другими нашими проектами мне нужен тег, чтобы запустить конвейер для развертывания.
Просто чтобы внести ясность: никому не разрешено переходить непосредственно в ветку разработки. Вместо этого разработчики должны представить свою работу в мерж-реквесте, который включает в себя некоторые проверки/конвейеры обеспечения качества. Это также означает, что принудительное нажатие на ветку запрещено.
В нашем GitLab, размещенном на собственном хостинге, используется http (вместо https).
Я хочу устранить необходимость вручную добавлять тег в репозиторий каждый раз, когда мерж-реквест объединяется с веткой разработки. Это поможет стандартизировать наши теги и гарантировать, что мы никогда больше не забудем отправить тег.
Однако созданный нами конвейер тегов не может отправлять новый тег в ветку разработки и дает сбой. Мы еще не нашли способа автоматически отправлять тег в защищенную ветку. Мы адаптировали наш сценарий конвейера из этого поста:
tagging:
stage: deploy
rules:
- if: $CI_COMMIT_BRANCH == $DEV_BRANCH_NAME
script:
- git config --local user.name "${GITLAB_USER_NAME}"
- git config --local user.email "${GITLAB_USER_EMAIL}"
- tag = "dev-$CI_COMMIT_SHA"
- git tag "$tag"
- git push --tags http://gitlab-ci-token:$CI_JOB_TOKEN@$CI_SERVER_HOST/$CI_PROJECT_PATH.git HEAD:$DEV_BRANCH_NAME
в результате чего получается такой вывод конвейера:
$ git config --global user.name "${GITLAB_USER_NAME}"
$ git config --global user.email "${GITLAB_USER_EMAIL}"
$ tag = "dev-$CI_COMMIT_SHA"
$ git tag "$tag"
$ git push --tags http://gitlab-ci-token:$CI_JOB_TOKEN@$CI_SERVER_HOST/$CI_PROJECT_PATH.git HEAD:$DEV_BRANCH_NAME
remote: You are not allowed to upload code.
fatal: unable to access 'http://[self_hosted_url]/[path_to_service]/[service].git/': The requested URL returned error: 403
ERROR: Job failed: exit code 128
Сначала мы попробовали использовать оригинальный скрипт, о котором я упоминал выше, но получили сообщение об ошибке remote: HTTP Basic: Access denied. The provided password or token is incorrect or your account has 2FA enabled and you must use a personal access token instead of a password. // fatal: Authentication failed for [correct url].
Можно ли обойти защиту ветки разработки, чтобы мы могли запустить приведенный выше скрипт, сохраняя при этом требования к мерж-реквестам и защиту ветки от прямых отправок со стороны разработчиков, или можем ли мы изменить приведенный выше скрипт так, чтобы он позволял нам отправлять тег в репо?
Ответы 2
В моей компании мы не используем git, мы просто делаем POST к экземпляру CI_API_V4_URL.
Определение OpenApi здесь , а подробности об API тега здесь
Теги не связаны с ветками. Когда вы отправляете тег, вы не отправляете его в ветку. Поэтому правила защиты ветвей здесь не применяются (хотя, если у вас есть защищенные теги, это применимо). Основная проблема заключается в разрешениях учетных данных, которые вы используете. CI_JOB_TOKEN у вас нет прав на запись в репозиторий, поэтому вы не сможете использовать git для отправки коммитов или тегов. Однако эти токены имеют некоторые ограниченные разрешения API.
По иронии судьбы, вы не можете создавать теги с помощью CI_JOB_TOKEN, однако вы можете создавать релизы (которые, в свою очередь, могут создавать теги). Вы можете использовать API для создания выпуска или использовать ключевое слово Release:. Очевидно, что это имеет основной эффект создания релиза, но также создаст тег git, если он еще не существует.
myjob:
rules:
- if $CI_COMMIT_BRANCH == $DEV_BRANCH_NAME
# ...
script:
- echo "noop"
release:
tag_name: dev-$CI_COMMIT_SHORT_SHA
description: dev release for $CI_COMMIT_SHA
Все, что делает ключевое слово Release, — это запускает скрипт в задании, который использует Release-Cli gitlab, который использует API GitLab для создания выпуска. В принципе, вы также можете просто использовать Release API самостоятельно вместо использования ключевого слова release:.
Вы также можете использовать API для создания тега без создания релиза, но в последний раз, когда я проверял, CI_JOB_TOKEN не разрешено использовать эти конечные точки. Итак, если вы хотите создать тег без создания выпуска, вам может потребоваться создать соответствующий токен с авторизованной областью API (например, токен доступа к проекту, токен группового доступа, токен личного доступа или аналогичный) и использовать это в твоей работе.
Связанная проблема в Gitlab: Разрешить отправку CI_JOB_TOKEN в собственный репозиторий