starlark-dev
Kurtosis Starlarkパッケージの開発とデバッグができます。パッケージをゼロから作成し、プラン基盤の実行モデルを理解し、print()デバッグを使用し、将来の参照を処理し、ローカルでパッケージをテストします。.starファイルの作成やトラブルシューティング時に使用してください。
description の原文を見る
Develop and debug Kurtosis Starlark packages. Create packages from scratch, understand the plan-based execution model, use print() debugging, handle future references, and test packages locally. Use when writing or troubleshooting .star files.
SKILL.md 本文
Starlark Dev
Kurtosis Starlark パッケージを作成、デバッグ、テストします。
パッケージ構造
最小限の Kurtosis パッケージには 2 つのファイルが必要です:
my-package/
kurtosis.yml # Package metadata
main.star # Entry point
kurtosis.yml
name: github.com/your-org/my-package
main.star
def run(plan, args):
plan.add_service(
name="my-service",
config=ServiceConfig(
image="nginx:latest",
ports={
"http": PortSpec(number=80, transport_protocol="TCP"),
},
),
)
パッケージの実行
# ローカルパッケージを実行
kurtosis run ./my-package
# パラメータを指定して実行
kurtosis run ./my-package '{"param1": "value1"}'
# GitHub からリモートパッケージを実行
kurtosis run github.com/ethpandaops/ethereum-package
# カスタムコンフィグファイルを指定して実行
kurtosis run github.com/ethpandaops/ethereum-package --args-file config.yaml
# ドライラン(プランのみ、実行なし)
kurtosis run ./my-package --dry-run
実行モデル
Kurtosis Starlark は 2 つのフェーズで実行されます:
- 計画フェーズ — コードが実行され、アクションの計画が構築されます。
add_service()、exec()などはすぐには実行されず、フューチャーリファレンスを返します。 - 実行フェーズ — 計画が順序に従って実行されます。フューチャーリファレンスは実際の値に解決されます。
つまり、計画フェーズ中に plan.exec() の戻り値を Python レベルのロジック(if/else など)で使用することはできません。代わりに plan.verify() または plan.assert() を使用してください。
# 間違い: result は計画フェーズ中のフューチャーリファレンスで、実際の値ではない
result = plan.exec(service_name="my-service", recipe=ExecRecipe(command=["echo", "hello"]))
if result["output"] == "hello": # これは期待通りに動作しません
plan.print("matched")
# 正しい: 条件チェックに plan.verify を使用
result = plan.exec(service_name="my-service", recipe=ExecRecipe(command=["echo", "hello"]))
plan.verify(result["exit_code"], "==", 0)
print でのデバッグ
def run(plan, args):
plan.print("Args received: {}".format(args))
service = plan.add_service(
name="my-service",
config=ServiceConfig(image="nginx:latest"),
)
plan.print("Service IP: {}".format(service.ip_address))
plan.print("Service hostname: {}".format(service.hostname))
よく使われるパターン
サービスの準備状況を待機
plan.wait(
service_name="my-service",
recipe=GetHttpRequestRecipe(port_id="http", endpoint="/health"),
field="code",
assertion="==",
target_value=200,
timeout="60s",
)
サービス内でコマンドを実行
result = plan.exec(
service_name="my-service",
recipe=ExecRecipe(command=["cat", "/etc/hostname"]),
)
plan.verify(result["exit_code"], "==", 0)
plan.print("Hostname: {}".format(result["output"]))
ファイルをアップロード
config_template = read_file("./templates/config.toml")
artifact = plan.render_templates(
name="my-config",
config={
"config.toml": struct(
template=config_template,
data={"key": "value"},
),
},
)
plan.add_service(
name="my-service",
config=ServiceConfig(
image="my-image:latest",
files={"/etc/myapp": artifact},
),
)
他のパッケージからインポート
dependency = import_module("github.com/org/other-package/lib.star")
def run(plan, args):
dependency.some_function(plan)
テスト
ドライラン → 実行 → 検証のワークフローを使用します:
# 1. 実行せずにプランを検証
kurtosis run --dry-run ./my-package
# 2. 実行して出力を確認
kurtosis run ./my-package
# 3. 作成されたエンクレーブを検査
kurtosis enclave inspect <enclave-name>
# 4. サービスログを確認
kurtosis service logs <enclave-name> <service-name>
# 5. サービスにシェルで接続して状態を検証
kurtosis service shell <enclave-name> <service-name>
# 6. テスト後にクリーンアップ
kurtosis clean -a
よくあるエラー
| エラー | 原因 | 対処方法 |
|---|---|---|
cannot use future reference in if | Python ロジックでプランの結果を使用 | plan.verify() または plan.assert() を使用 |
service not found | サービス名のタイプミスまたは未作成 | plan.add_service() の名前が一致しているか確認 |
port not found | ポート ID の不一致 | レシピ内の port_id が ports ディクショナリのキーと一致しているか確認 |
image pull failed | イメージが存在しないか認証なし | イメージタグを確認し、docker pull を手動で確認 |
kurtosis.yml not found | 間違ったディレクトリから実行 | kurtosis.yml を含むパッケージルートから実行 |
ライセンス: Apache-2.0(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- kurtosis-tech
- ライセンス
- Apache-2.0
- 最終更新
- 2026/5/11
Source: https://github.com/kurtosis-tech/kurtosis / ライセンス: Apache-2.0
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。