| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed |
@ayufan
|
@grzegorz
|
@dhershkovitch
@gabrielengel_gl
| devops verify | 2023-08-23 |
GitLab Steps を実行する Step Runner
要約
このドキュメントでは、Step Runnerという新しいコンポーネントのアーキテクチャ、使用するGitLab Steps構文、GitHub Actionsのサポートについて説明します。
競合のCI製品であるdrone.ioや GitHub Actionsは、ステップ（アクション）の形でComposer CIジョブを実行します。
これらの使い方とGitLab Runner Pluginsの事前評価から、CIジョブの実行を定義するためのより良い方法の必要性がわかりました。
用語解説
- GitLab Steps: GitLab CI機能の一つで、単一のジョブ実行コンテキスト内で再利用可能なコンポーネントを定義し、使用するための機能。
- Step Runner: GitHub Actionsとの互換性を提供するGitLab StepsのRFC実装。
- GitHub Actions: GitLab Stepsと同様、GitHubで使用される再利用可能な実行コンポーネント。
- CI Catalog: 公開または非公開のコンポーネントカタログ。
- GitLab Rails: GitLab.comまたはオンプレミスインストールで動作する、パイプライン実行を担当するメインアプリケーション。
動機
現在の.gitlab-ci.yml はそれなりに柔軟ですが、複雑なワークフローをサポートしようとすると、非常に複雑になりがちです。この複雑さは、繰り返しパターン、目的に特化した構文、または実行するコマンドの複雑なシーケンスで表現されます。
特に、.gitlab-ci.yml は、CIジョブの実行に微調整や特別な動作を必要とするような複雑なワークフローでは柔軟性に欠けるため、これは非常に困難です。Gitクローンの扱い方、アーティファクトのダウンロードのタイミング、シェルスクリプトの実行方法などが規定されているため、”標準 “ではないパイプラインや新しい機能が要求された場合には、システムを回避する必要が生じることがよくあります。
これは、secure files やrelease: キーワードのような特定の機能をサポートするために、.gitlab-ci.yml に新しい構文を追加しようとする場合に、特に困難となります。このような特別な機能をシンタックスレベルで追加すると、コンフィグがより複雑になり、メンテナーが難しくなり、要件が変更されたときに技術的負債に対処するのがより複雑になります。
drone.io とGitHub Actions の例を見ると、多くのワークフローはCIのシンタックスの一部である必要はありません。その代わりに、CIコンフィグに汎用的な方法で設定された再利用可能なコンポーネントの形で提供し、後でダウンロードして入力とパラメータに従って実行することができます。
GitLab Stepsは、競合他社と同様のモデルを採用し、ある程度互換性を保つことで、このプロダクトギャップを埋めることを意図しています。GitLab Stepsは、特定の機能を処理するための全ての目的特有の構文を置き換えることを意図しています。.gitlab-ci.yml の内部で構築され、バージョン管理され、必要な時に要求される再利用可能なコンポーネントを提供し、使用することで、顧客はより柔軟になり、私たちはより速くカタログを反復することができます。
CIジョブ実行の一部である再利用可能なコンポーネントは、GitLab.com上のパブリックにホストされたリポジトリから使用することも、オンプレミスのステップのリポジトリから使用することも、ローカルプロジェクトから取得することもできます。
各CIジョブは実行するsteps: 、GitLabステップまたはGitHubアクションを参照するリストを定義します。これらのステップはステップランナーによってターゲット環境のコンテキストで直接実行されます。GitLab RunnerはGitLab.com（またはオンプレミスのインストール）とStep Runnerの接続を担当します。
目標
GitLabのステップ：
- GitLab StepsはGitLab特有のSteps実装のための構文と構造を定義します。
- GitLab StepsはCI Catalogで公開されています。
- GitLab Stepsはインスタンスをまたいで利用することができます（フェデレーション）。
- GitLab Steps は
inputsとoutputsを定義しています。 - GitLab Stepsは機密情報を期待される権限で明示的に要求する必要があります。例えば、シークレット、変数、トークンなどです。
GitLab StepsのリポジトリはGitLab Inc.が管理しています：
- GitLab Inc.が提供するGitLab Stepsのリポジトリは、現在のすべての目的別構文のドロップイン代替となります：
artifacts:cache:,release:, など。 - GitLab Inc.は様々なShellをサポートする
shellステップを実行する汎用ステップを提供します(bash,powershell)。 - 目的固有の構文の使用は、最終的には廃止され、ステップに取って代わられるかもしれません。
ステップランナー：
- Step Runnerは
https://gitlab.com/gitlab-orgの別プロジェクトでホストされています。 - Step Runner を使うと、ほとんどの GitHub Actions を実行できます。
- ステップランナーはターゲット環境でプロセスとして実行されます。
- Step Runnerは、ローカルマシンのユーザーが、ローカルに保存された
.gitlab-ci.ymlから特定のCIジョブのステップを実行するために使用できます。 - Step RunnerはGitLab Runnerの外部コンポーネントであり、GitLab Runnerは環境のプロビジョニング、ペイロードの構築、Step Runnerへの実行を行います。
- Step RunnerはGitLab Runnerの
clone、artifacts、caches、script、after_script、全ての異なるShell (bash、powershell) のカスタムハンドリングを置き換えるものです。 - Step Runner は GitLab Steps と GitHub Actions のパースとコンパイルを担当します。
- Step RunnerはGitLab StepsとGitHub Actionsが必要とするリポジトリのダウンロードと管理を担当します。
- Step Runnerは個々の実行ステップの実行フローの制御と監視を行います。
- Step Runnerは、コマンドラインインターフェイス(CLI)。つまり、設定ファイル、環境ファイル、または
.gitlab-ci.ymlを読み込んで設定することができます。 - Step Runnerは、コンフィグを実行したりトレースを取得したりするために、gRPCやその他のプログラム可能なインターフェースを公開することができます。
ステップの実行
- 各ステップは、1つの公開されたGitLabステップ、またはローカルで定義されたGitHubアクションによって定義されます。
- 各ステップはそのステップで定義された条件によって実行されます。
- 各ステップは、最も少ない情報量で実行されます。ステップに公開される情報は、ステップから明示的に要求されたものです。例えば、ステップから明示的に要求された環境変数のみがステップに渡されます。
- 各ステップは信頼されていないとみなされます。一部のステップが信頼されていても、システムは信頼を保証できないので、CIジョブ全体は信頼されていないと考えるべきです。
- 各ステップは、その実行を、前提条件、使用されるバージョン、生成される出力の形で記述します。これは、再現可能なビルドを作成する目的で、ステップの実行を署名できるようにするためのものです。
後方互換性：
- 現在実行可能なすべての構文（例：
before_script:,script:,artifacts:,cache:, など）はGitLab（Rails）で変換可能であるべきです。
非ゴール
未定
提案
未定
デザインおよび実施内容
未定