This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
StatusAuthorsCoachDRIsOwning StageCreated
proposed @furkanayhan @grzesiek @jreporter @cheryl.li devops verify 2023-03-15

GitLab CIイベント

要約

イノベーションを起こし、より多くの価値を構築するために、GitLabはDevSecOpsプロセスに関する自動化の中心になることが期待されています。私たちはGitLabをプログラミング環境に変え、エンジニアがCI/CDパイプラインの上で様々なワークフローをモデル化できるようにしたいと考えています。今日、ユーザーは必要なワークフローを構築するために、Webhookやスケジュールされたパイプラインを中心にカスタム自動化を作成しなければなりません。

ユーザーにとってこの自動化をより簡単にするために、私たちは強力なCI/CDイベントシステムを構築したいと考えています。

典型的なユースケースは、誰かがイシューを作成したりコメントを投稿したり、マージリクエストのステータスを “draft” から “ready for review” に変更したり、グループに新しいメンバーを追加したりしたときに CI/CD ジョブを実行することです。

そのような新しい技術を構築するには

  1. GitLab 内から多くの階層イベントを、現在よりも高度な方法で発信すること。
  2. GitLabのイベントに反応する自動化を、大規模に実行するのに手頃な価格にしましょう。
  3. 自動化を簡単に書くための規約とライブラリのセットを提供します。

目標

GitLab Events Platform “がGitLabのイベント発信に関する新しい抽象化を構築することを目的としているのに対して、”GitLab CI Events “の設計図は以下のことを可能にすることを目的としています：

  1. イベントがいつCIパイプラインを実行するかをユーザーが設定する方法を定義します。
  2. GitLab.comスケールやそれ以上のスケールで、サブスクリプションとイベントをマッチさせるために必要なテクノロジーを説明します。
  3. 自動化ジョブの実行コストを大幅に削減するために利用できる技術を説明してください。

提案

要件

採用されたプロポーザルは、以下の要件および特徴を考慮する必要があります：

  1. To-Doイベントの定義は別ファイルで行ってください。
    • すべてのイベントを1つのファイルで定義すると、1つのファイルが複雑になりすぎて、ユーザーがメンテナーするのが難しくなります。そして、ユーザーは、include キーワードでコンフィグを再び分離する必要があります。
    • パイプライン、ペルソナ、ジョブの構造は、サブスクライブされるイベントとサブスクリプションの目的によって異なります。
  2. 1つのサブスクリプション設定ファイルは、イベントがトリガーされたときに作成される1つのパイプラインを定義します。
    • パイプライン設定ファイルはinclude キーワードで他のファイルを含めることができます。
    • パイプラインは多くのジョブを持つことができ、子パイプラインやマルチプロジェクトパイプラインをトリガーします。
  3. イベントと処理構文は、実用的であれば既存のCI設定構文を使うべきです。
    • その方がユーザーが適応しやすいでしょう。実装の手間が省けます。
  4. イベントサブスクリプションとイベントの発行は、パフォーマンスが高く、スケーラブルで、ノンブロッキングであるべきです。
    • 通常、データベースからの読み込みはファイルからの読み込みよりも高速です。
    • CIイベントは多くのサブスクリプションを持つ可能性があります。パイプラインを作成するために適切なYAMLファイルを評価することも含まれます。
    • メインのビジネスロジック (イシューの作成など) は、与えられた CI イベント (イシューの作成など) へのサブスクリプションの影響を受けないようにします。
  5. CIイベントの設計は、メンテナーで拡張可能な方法で実装されるべきです。
    • issues/create イベントがあれば、新しいイベント(merge_request/created)を追加することができます。
    • 私たちは、多くのイベントが追加されることを期待しています。開発者にとっては、ドメインイベント（例えば ‘イシューがクローズした’ など）を GitLab 定義の CI イベントとして登録するのは簡単なことでしょう。
    • また、ユーザー定義のCIイベント（例えば’order shipped’）を長期的にサポートする機会も検討すべきです。

オプション

今のところ、技術的な5つの提案があります；

  1. 提案1：.gitlab-ci.yml ファイルの使用 に基づいています；
  2. 提案2:rules キーワードを使う 非常に非効率な方法。
  3. 提案3:.gitlab/ci/events フォルダーを使う イベントごとにファイルを読み込む必要があります。
  4. 提案4: CI設定ファイルによるイベントの作成イベントを定義するための設定ファイルを別に用意。
  5. 提案5：複合提案上記の提案の組み合わせ。