web-dev-qa-db-ja.com

CIビルドで複数のリポジトリにアクセスする方法

複数の（非公開）リポジトリで構成されるプロジェクトがあります。

プロジェクト全体をビルドするには、ビルドシステムにすべてのリポジトリのファイル（masterブランチ）が必要です。

GitLab CIを構成して、必要なリポジトリを提供する方法はありますか？

私はgit fetchまたはCIビルド中に類似していますが、認証をどのように処理しますか？

gitlabgitlab-ci
32
Udo G

すべてのプロジェクトに展開キーを追加できます。次に、ランナーで展開キーの秘密キーを設定します。ビルドプロセスで通常のgitコマンドを使用して、ランナーのリポジトリを複製します。これにはランナーの設定が多少必要になる場合がありますが、動作するはずです。

1つのSSHキーペアを生成してすべてのランナーで使用するか、ランナーごとに1つのキーペアを生成できます。 SSHキーペアを生成するには、 SSHキー ドキュメントに従います。秘密鍵は「gitlab-runner」ユーザーの.sshディレクトリ。これにより、gitコマンドでクローン時に表示できます。公開キーは、デプロイキーとしてGitLabプロジェクトに追加する必要があります。プロジェクト設定で展開キーを追加-> 'キーの展開'。

4
Drew Blessing

Gitlabバージョン8.12以降を実行している場合、パーミッションモデルは reworked でした。この新しい許可モデルに加えて、CI環境変数CI_JOB_TOKEN。 GitLabのプレミアムバージョンは、トリガーにこの環境変数を使用しますが、リポジトリを複製するために使用できます。

dummy_stage:
  script:
    - git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.instance/group/project.git
77
microe14

回避策がいくつかあります（この言葉は嫌いです！）：

  1. git submoduleを使用して、 https://docs.gitlab.com/ce/ci/git_submodules.html を参照してください

  2. Gitlabによって定義され、子Dockerコンテナー内でも使用可能な$ CI_REPOSITORY_URLを再利用します。このenv変数にはすでにユーザー名とパスワードが含まれており、同じサーバー上の別のリポジトリに使用できます。 。gitlab-ci.ymlのスニペットを参照してください：

-BASE_URL = `echo $ CI_REPOSITORY_URL | sed "s; \/* $ CI_PROJECT_PATH。* ;;" `
-REPO_URL =" $ BASE_URL/thirdparty/gtest.git "
-REPO_DIR = thirdparty/gtest 
- rm -fr $ REPO_DIR 
-git clone $ REPO_URL $ REPO_DIR
  1. そのURLを〜/ .git-credentialsファイルにusername\passwordで保存し、credential.helper経由でそれを使用するようにgitを設定します。それ以降の「git clone」コマンドはすべてこれを使用します。
-echoユーザー名とパスワードなしの「git clone」コマンドで使用されるgitクレデンシャルの保存... 
-GIT_CREDENTIALS_FILE =〜/ .git-credentials 
-BASE_URL = `echo $ CI_REPOSITORY_URL | sed "s; \/* $ CI_PROJECT_PATH。* ;;" `
-echo $ BASE_URL> $ GIT_CREDENTIALS_FILE 
-git config --global credential.helper store --file = $ GIT_CREDENTIALS_FILE

しかしながら ！

CI\CD分野でかなりの年数を費やしてきたので、リポジトリをsourcesとしてリンクする必要がある良いデザインだとは思いません。

はい、JenkinsやTeamCityなどの従来のCIツールでは、異なるサブディレクトリにある複数のGitリポジトリを取得するジョブを作成できます。

しかし、GitLab CIのPipeline As Codeの方法が好きです。ここでは.gitlab-ci.ymlがこの非常にレポのビルドを制御し、ソースを取得するビルド前のステップ全体について考える必要さえありません。次に、そのようなビルドはbinaryアーティファクトを公開し、ダウンストリームプロジェクト\ reposはsources依存関係。また、高速です。

関心事の分離。

.gitlab-ci.ymlに別のプロジェクトのアーティファクトを使用する公式な方法はありません。ただし、フック、Gitlab APIなどの他の方法もありますが、そのような特注のソリューションにはメンテナンスが必要です。

より良い方法があります-広く採用されている外部のPackage Managerからアーティファクトを公開\フェッチします。言語によっては、Maven、NuGet、npm、jFrog Artifactory、Nexusなどがあります。このメソッドのもう1つの利点は、開発者がローカルビルドで同じプロセスをたどることができることです。 -ci.yml

これは主にバイナリインターフェイスの互換性によるネイティブコード（Cxx）の大きな問題ですが、Conan.ioなどのようなものが徐々に追いついてきています。

9
Ivan