Как отправить тег в ветку в CI?

Я хочу добавить ручные задания к моему запросу на слияние, чтобы пометить мою исходную ветку, когда я запускаю ручные задания. Этот тег запустит сборку моей конфигурации bitrise.

Однако когда я пытаюсь нажать на свой тег, я сталкиваюсь с этой проблемой. NB: ветка, на которую я пытаюсь отправить свой тег, НЕ защищена.

$ git checkout $CI_COMMIT_REF_NAME
Switched to a new branch 'feature/gitlab-ci'
Branch feature/gitlab-ci set up to track remote branch feature/gitlab-ci from origin.
$ git tag build-bitrise
$ git push --tags
remote: You are not allowed to upload code.
fatal: unable to access 'https://gitlab-ci-token:[MASKED]@gitlab.com/my-app/my-app.git/': The requested URL returned error: 403
Cleaning up file based variables
00:01
ERROR: Job failed: exit code 1

Моя работа такова:

    - git remote show origin
    - git fetch
    - git checkout $CI_COMMIT_REF_NAME
    - git tag build-bitrise
    - git push --tags

На шаге before_scripts я делаю:

before_script:
    # Install ssh-agent through openssh-client if not present
    - 'which ssh-agent || ( apt-get update -qy && apt-get install openssh-client -qqy )'
    # Add the private key to this user
    - eval $(ssh-agent -s) && ssh-add <(echo "$SSH_PRIVATE_KEY") && mkdir -p ~/.ssh
    # Config git to avoid first usage questions. Set the identity
    - git config --global user.email "[email protected]" && git config --global user.name "Louis Lecocq"

Где SSH_PRIVATE_KEY - это переменная, которая является копией / вставкой моего профиля GITLAB в ENV.

Спасибо за чтение и ваше время


git gitlab bitrise
person Louis Lecocq    schedule 16.11.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я думаю, что ваш текущий метод не работает, потому что он все еще использует https, а не ssh для выполнения git tag в соответствии с сообщением об ошибке, поэтому не использует ваш SSH_PRIVATE_KEY:

fatal: unable to access 'https://gitlab-ci-token:[MASKED]@gitlab.com/my-app/my-app.git/': The requested URL returned error: 403

Вы могли бы получить эту работу (непроверенной), обновив git remote вручную, прежде чем делать git push --tags, то есть с помощью:

git remote set-url origin [email protected]:my-group/my-app/my-app

Альтернативой использованию SSH_PRIVATE_KEY является использование ключа API. Вы можете создать личный токен доступа с доступом API из https://gitlab.com/-/profile/personal_access_tokens, а затем добавьте ключ в CI/CD Variables, например, как API_KEY.

Затем в разделе сценария вы можете иметь что-то похожее на:

script:
    - # something to do before pushing the tag
      # sometimes the remote might already exist (if using the same runner), let's just remove it and don't fail
    - git remote remove https-origin || true
      # add new https-origin remote which uses the API_KEY
    - git remote add https-origin https://gitlab-ci-token:${API_KEY}@gitlab.com/my-group/my-app.git
      # tag your build
    - git tag build-bitrise
      # push only the build-bitrise tag using the https-origin ref, and skip CI build
    - git push https-origin -o ci.skip refs/tags/build-bitrise

NB, рекомендовал бы использовать учетную запись бота для API_KEY, иначе API_KEY будет иметь те же разрешения, что и ваш пользователь, и может быть пропущен другими специалистами по обслуживанию, которые смогут видеть ключ в переменных CI / CD и т. Д.

person Rekovni    schedule 18.11.2020
comment
Спасибо, Рековни. Действительно, я закончил тем, что попытался использовать SSH_PRIVATE_KEY + личный токен доступа и вручную установить git remote set-url origin gitlab-ci-token: $ GITLAB_TOKEN @ $ CI_SERVER_HOST / Однако, вместо использования токена персонального доступа, могу ли я использовать токен развертывания из самого проекта gitlab? - person Louis Lecocq; 19.11.2020
comment
Я не верю в это, поскольку токены развертывания не имеют write_repository разрешения, только read_repository - person Rekovni; 19.11.2020