Как gitlab-CI может устанавливать частные пакеты python из зависимости gitlab, которая также относится к репозиториям gitlab - PullRequest
Новая
       54

Как gitlab-CI может устанавливать частные пакеты python из зависимости gitlab, которая также относится к репозиториям gitlab

0 голосов
/ 30 мая 2019

Этот вопрос о том, как управлять доступом для частных пакетов Python gitlab с вложенными зависимостями от других частных пакетов gitlab. Предполагается, что весь доступ осуществляется через шаблоны прямого git-репозитория, а не частный репозиторий пакетов.

package-a находится в частном репозитории gitlab и зависит от package-b, который зависит от package-c, и они также находятся в частном репозитории gitlab.

package-a имеет pyproject.toml как это: 

[tool.poetry]
name = "package-a"
repository = "https://gitlab.com/org/package_a.git"

[tool.poetry.dependencies]
python = "^3.6"
package-b = {git = "ssh://git@gitlab.com/org/package_b.git", tag = "0.1.0"}

package-b имеет pyproject.toml как это: 

[tool.poetry]
name = "package-b"
repository = "https://gitlab.com/org/package_b.git"

[tool.poetry.dependencies]
python = "^3.6"
package-c = {git = "ssh://git@gitlab.com/org/package_c.git", tag = "0.1.0"}

Любой пользователь с правом участия org в gitlab и ssh-ключе может использовать poetry для установки package-a, его зависимость от package-b, а затем зависимость от package-c, все в python venv на разработке ноутбука. Доступ по протоколу ssh также работает для сборок докеров (с экспериментальными функциями для монтирования ssh).

Однако те же проекты с частными зависимостями не установлены в бегунах gitlab-CI, потому что у них нет доступа по ssh. (Есть ли безопасный способ включить это?)

Предполагая, что бегуны gitlab-CI должны использовать токен доступа для клонирования частных репозиториев gitlab, сценарий sed применяется к файлу pyproject.toml для project-a, поэтому gitlab-CI бегун может клонировать package-b, чтобы обнаружить, что это зависит от package-c; сценарий sed изменяет ssh на доступ https для project-b путем редактирования спецификации зависимости project-a в pyproject.toml, т.е. 

sed -i -e 's#ssh://git@gitlab.com/org#https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/org#g' pyproject.toml

CI_JOB_TOKEN - это переменная окружения, предоставляемая средством запуска gitlab-CI. Он надежно управляется бегуном gitlab-CI. Итак, бегун gitlab-CI теперь может клонировать репозиторий project-b где-нибудь . Тот же прием уловки может сработать, если его применить к этому project-b хранилищу где-то , но теперь он находится в руках poetry и к нему нельзя прикоснуться. Таким образом, project-b имеет зависимость git + ssh от project-c, а исполнителю gitlab-CI не удается установить project-c, поскольку у него нет учетных данных git + ssh для его клонирования.

Таким образом, цепочка зависимостей закрытых пакетов работает для разработки и сборки докеров на ноутбуке с доступом git + ssh, но все это не работает на gitlab-CI. Как лучше управлять доступом к частным пакетам во всех этих средах сборки?

1 Ответ

0 голосов
/ 30 мая 2019

Эти фрагменты основаны на: 

ssh-keygen -o -t rsa -b 4096 -C "git@gitlab.com"

# output to something like ~/.ssh/gitlab_ci_rsa
# do not add any passphrase

# once created, copy the private key to the clipboard, e.g.
cat ~/.ssh/gitlab_ci_rsa | base64 -w0 > tmp.txt
xclip -sel clip < tmp.txt

Открытый ключ используется в качестве частного ключа развертывания, который активируется на странице настроек проекта, например,

Закрытый ключ вставляется в переменную gitlab-CI SSH_PRIVATE_KEY, и gitlab должен иметь возможность его маскировать (если он закодирован base64).Затем файл .gitlab-ci.yml может добавить этот закрытый ключ в ssh-agent с помощью: 

before_script:
  - apt-get update -y -qq && apt-get install -y -qq git make openssh-client
  - eval $(ssh-agent -s)
  ## Add the SSH key stored in SSH_PRIVATE_KEY variable to the agent store
  - ssh-add <(echo "$SSH_PRIVATE_KEY" | base64 --decode)
  ## Create the SSH directory and give it the right permissions
  - mkdir -p ~/.ssh
  - chmod 700 ~/.ssh
  - ssh-keyscan gitlab.com >> ~/.ssh/known_hosts
  - chmod 644 ~/.ssh/known_hosts

В документации gitlab не используется кодировка base64, но важно скопировать весь закрытый ключ впеременная, что позволяет избежать запроса пароля от ssh-add.

...