Status | Authors | Coach | DRIs | Owning Stage | Created |
---|---|---|---|---|---|
proposed | - |
コンポーネントリポジトリの開発ワークフロー
要約
このページでは、コンポーネントリポジトリを作成する手順について説明します。プロジェクトの作成から新しいリリースをカタログページに表示するまでに必要なすべてのステップについて説明します。
1.新規プロジェクトの作成
まず、新しいプロジェクトを作成し、README.md
ファイルを追加します。これは、リポジトリがカタログリソースになるために、将来必要となる予定です。
2.リポジトリ内にコンポーネントを作成します。
リポジトリ内にコンポーネントを1つだけ持つつもりなら、ルートディレクトリに定義できます。そうでない場合は、コンポーネント用のディレクトリを作成してください。詳細は、コンポーネントリポジトリのディレクトリ構造を参照してください。
この例では、ルートディレクトリに1つのコンポーネントを定義しています。
コンポーネントとして提供したい設定を含むtemplate.yml
ファイルを作成します:
spec:
inputs:
stage:
default: test
---
.component-default-job:
image: busybox
stage: $[[ inputs.stage ]]
component-job-1:
extends: .component-default-job
script: echo job 1
component-job-2:
extends: .component-default-job
script: echo job 2
上記のコンポーネント設定例では、component-job-1
とcomponent-job-2
という2つのジョブをパイプラインに追加しています。
3.CI でのテスト変更
コンポーネントにプッシュされた変更をテストするために、ルートディレクトリに.gitlab-ci.yml
を作成します:
##
# This configuration expects an access token with read-only access to the API
# to be saved as in a masked CI/CD variable named 'API_TOKEN'
include:
# Leverage predefined variables to refer to the current project and SHA
- component: gitlab.com/$CI_PROJECT_PATH@$CI_COMMIT_SHA
stages: [test, release]
# Expect all `component-job-*` jobs are added
ensure-jobs-added:
image: badouralix/curl-jq
script:
- |
route="https://gitlab.com/api/v4/projects/$CI_PROJECT_ID/pipelines/$CI_PIPELINE_ID/jobs"
count=`curl --silent --header "PRIVATE-TOKEN: $API_TOKEN" $route | jq 'map(select(.name | contains("component-job-"))) | length'`
if [ "$count" != "2" ]; then
exit 1
fi
# Ensure that a project description exists, because it will be important to display
# the resource in the catalog.
check-description:
image: badouralix/curl-jq
script:
- |
route="https://gitlab.com/api/v4/projects/$CI_PROJECT_ID"
desc=`curl --silent --header "PRIVATE-TOKEN: $API_TOKEN" $route | jq '.description'`
if [ "$desc" = "null" ]; then
echo "Description not set. Please set a projet description"
exit 1
else
echo "Description set"
fi
# Ensure that a `README.md` exists in the root directory as it represents the
# documentation for the whole components repository.
check-readme:
image: busybox
script: ls README.md || (echo "Please add a README.md file" && exit 1)
# If we are tagging a release with a specific convention ("v" + number) and all
# previous checks succeeded, we proceed with creating a release automatically.
create-release:
stage: release
image: registry.gitlab.com/gitlab-org/release-cli:latest
rules:
- if: $CI_COMMIT_TAG =~ /^v\d+/
script: echo "Creating release $CI_COMMIT_TAG"
release:
tag_name: $CI_COMMIT_TAG
description: "Release $CI_COMMIT_TAG of components repository $CI_PROJECT_PATH"
このパイプラインには、いくつかのタスクの例が含まれています:
- コンポーネントを使用して、最終的な設定が有効な構文を使用していることを確認します。また、入力やシークレットなど、コンポーネントが動作するための最小限の要件が整っていることも確認します。
- 作成されたパイプラインが期待される特性を持つことをテストします。例えば、
component-job-*
ジョブがパイプラインに追加されていることを確認します。-
パイプライン API エンドポイントを
curl
で呼び出し、jq
を介してデータを解析します。 - このテクニックを使えば、ユーザーは特定のジョブが含まれているか、ジョブには正しいプロパティが設定されているか、ログには期待される出力が含まれているかなどを確認できます。
-
パイプライン API エンドポイントを
- プロジェクトの説明が設定されていることを確認します。
- リポジトリに
README.md
ファイルがあることを確認してください。 - 自動的にリリースを作成します。タグが作成され、特定の正規表現に従った場合、以前のチェックがすべて通過した後にリリースを作成します。
4.パイプラインの実行
変更をプッシュするか手動でパイプラインを実行して、main
ブランチの新しいパイプラインを実行します:
5.タグを作成します
main
のパイプラインが緑色なので、最初のタグを作成することができます:v1.0
.
v1.0
タグが作成されるとすぐに、タグのパイプラインが開始されます。今回のパイプラインには、release
のステージにcreate-release
のジョブもあります:
create-release
のジョブが終了すると、リリースメニューに新しいリリースが表示されます:
6.リポジトリをカタログに公開します。
コンポーネントリポジトリと新しいリリースの両方がCIカタログに表示されるようにするには、リポジトリを公開する必要があります。
コンポーネントリポジトリを公開すると、カタログリソースになります。
このアクションのAPIエンドポイントは開発中です。詳細はイシューをお読みください。