• エントリーポイントファイルのバリアントなし

GitLab CIイベント提案5：統合提案

この提案では、イベントのまとまったグループのために別々のファイルを用意します。このファイルはメインの.gitlab-ci.yml 設定ファイルに含まれます。

# my/events/packages.yaml

spec:
  events:
    - events/package/published
    - events/audit/package/*
  inputs:
    env:
---
do_something:
  script: ./run_for $[[ event.name ]] --env $[[ inputs.env ]]
  rules:
    - if: $[[ event.payload.package.name ]] == "my_package"

.gitlab-ci.yml ファイルでは、サブスクリプションを有効にすることができます：

# .gitlab-ci.yml

include:
  - local: my/events/packages.yaml
    inputs:
      env: test

GitLabはインクルードされたファイルの変更を検出し、そのspecを解析します。サブスクリプションを定義するのに必要な情報は全てspecにカプセル化されているので、ファイル全体を読む必要はありません。spec のヘッダを読み取り、ワークフロー識別子となるチェックサムを計算することができます。

新しい識別子を見つけたら、特定のプロジェクトのためにサブスクリプションを再定義し、それらをデータベースにアップサートすることができます。

パイプラインを実行するために、パブリッシャーとサブスクライバーをマッチングするために、効率的な GIN インデッ クスマッチング技術を使用します。

この構文は CI Components とも互換性があり、GitLab 内で発生したイベントに対してのみ実行されるように設計されたコンポーネントを簡単に定義することができます。

エントリーポイントファイルのバリアントなし

この提案のもう一つの変形は、単一のGitLab CI YAML設定ファイルから離れることです。その場合、.gitlab/workflows/ のような別の検索ディレクトリを定義し、そこにすべてのYAMLファイルを保存します。

include ワークフロー/イベントファイルはGitLabが自動的に見つけるので、どこかに置く必要はありません。この機能を実装するには、”custom location for.gitlab-ci.yml file” のような機能を拡張する必要があります。

例えば、メインの設定ファイルを使わずに（GitLab CI YAMLファイルはまだサポートされています）：

# .gitlab/workflows/push.yml

spec:
  events:
    - events/repository/push
---
rspec-on-push:
  script: bundle exec rspec

# .gitlab/workflows/merge_requests.yml

spec:
  events:
    - events/merge_request/push
---
rspec-on-mr-push:
  script: bundle exec rspec

# .gitlab/workflows/schedules.yml

spec:
  events:
    - events/pipeline/schedule/run
---
smoke-test:
  script: bundle exec rspec --smoke