プラグインの自動リリース

このページ

自動リリースは、バージョンタグをプッシュするか、GitHub Actionsワークフローを手動で開始すると、サンドボックスプラグインをビルドして公開します。あなたのAtmosphereアカウントがパッケージプロファイルとリリースレコードを所有します。GitHubが承認済みワークフローを識別し、リリースサービスがリポジトリにアカウント認証情報を保存せずに結果を検証・公開します。

コンピューターから開始するリリースにはemdash-plugin publishを使用してください。GitHub Actionsがリリースのビルドと公開を行う場合はこのガイドを使用してください。

前提条件

開始前に以下を準備してください:

  • サンドボックスEmDashプラグインを含むパブリックGitHubリポジトリ。
  • slugpublisherlicense、著者、セキュリティ連絡先を含む有効なemdash-plugin.jsoncrepoを正規のGitHub URLに設定するか、対話式セットアップ中に入力してください。
  • package.json内のバージョン、またはレジストリ専用プラグインの場合はemdash-plugin.jsonc内のバージョン。
  • publisherで指定されたAtmosphereアカウント。
  • リポジトリにGitHub Actionsシークレットを追加する権限。
  • パスキーをサポートするブラウザ。リリース承認にはユーザー検証が必要です。

ワークフローを設定する前にマニフェストチェックを実行してください:

pnpm exec emdash-plugin validate

自動リリースの設定

  1. パッケージを所有するAtmosphereアカウントでプラグインCLIにサインインします。

    pnpm exec emdash-plugin login alice.example.com

    CLIはこのローカル公開セッションをプロジェクト外に保存します。GitHub Actionsはこれを受信しません。

  2. パッケージプロファイルを準備し、ワークフローを生成します。

    pnpm exec emdash-plugin release setup

    コマンドはemdash-plugin.jsoncからパッケージメタデータを読み取ります。パッケージプロファイルが存在しない場合、作成を提案します。プロファイルが存在するが委任リリース設定がない場合、既存のパッケージメタデータを保持しながら追加を提案します。

    セットアップはリリースに承認が必要なタイミングを尋ねます:

    • プラグインの権限が増加した場合がデフォルトです。宣言されたアクセスが最新のリリースに対して拡張された場合、リリースは承認を待ちます。
    • すべてのリリースに対してはすべてのバージョンに対して承認を要求します。

    サインイン中のAtmosphereアカウントが初期承認者になります。プロファイルはまた、パッケージを正規のGitHubリポジトリURLにバインドし、検証可能な来歴を要求します。

    ワークフローファイルが既に存在する場合はプロファイルステップのみを実行してください:

    pnpm exec emdash-plugin profile setup

    非対話型ターミナルでは、--yesを渡してデフォルトの承認ポリシーを受け入れます。マニフェストにrepoが含まれていない場合は--repository <https-url>を、すべてのリリースに対して承認を要求する場合は--confirmation alwaysを渡してください。

  3. 生成されたワークフローをレビューしてコミットします。

    コマンドは.github/workflows/emdash-release.ymlを作成します。ファイルをプッシュせず、--forceを渡さない限り既存のワークフローを置き換えません。

    生成されたワークフローはv*に一致するバージョンタグとworkflow_dispatchで実行されます。contents: readid-token: writeattestations: writeを付与し、サードパーティActionsを完全なコミット識別子に固定し、1つのプラグインバンドルをビルドし、それらの正確なバイトに対するGitHubビルド来歴を作成し、両方のファイルをEmDashリリースActionに渡します。

  4. リリースサービスダッシュボードを開き、同じAtmosphereアカウントでサインインします。

    Authorize publishingを選択します。アカウントプロバイダーが正確な委任権限を表示します。保持された付与はパッケージリリースレコードの作成とパッケージまたはリスティング画像のBlobアップロードが可能です。パッケージプロファイルの作成・編集、リリースの更新・削除、他のコレクションへの書き込みはできません。

  5. ワークフロー招待を作成します。

    emdash-plugin.jsoncからプラグインIDを入力し、Create invitationを選択します。ワンタイム値をGitHubリポジトリにEMDASH_CONNECTION_INVITATIONという名前のActionsシークレットとして追加します。

    招待は30分間有効で、指定されたプラグインのみに接続できます。ワークフローが消費する前に期限切れになった場合は新しい招待を作成してください。

  6. リリースワークフローを開始します。

    バージョンタグを作成する前にパッケージバージョンを更新します。以下のコマンドで1.2.3リリースを開始します:

    git tag v1.2.3
    git push origin v1.2.3

    リポジトリのGitHub ActionsページでRun workflowを選択することもできます。

  7. 初回実行時にワークフロー接続を承認します。

    ActionがGitHubジョブサマリーにリンクを書き込み、待機します。リンクを開き、プラグイン、リポジトリ、ワークフローファイル、ブランチまたはタグ、環境を確認します。

    タグトリガーの実行では、All version tagsまたはOnly this tagを選択します。ブランチトリガーのリクエストはそのブランチのみをカバーします。サービスはGitHubリポジトリとオーナーIDおよび選択されたrefと環境スコープを保存します。以降の実行はこのポリシーに一致する必要があります。

  8. 必要に応じてリリースを承認します。

    プラグインの権限を拡張するリリース、またはすべてのリリースに対する確認が設定されたプロファイルは、Awaiting approval状態になります。Actionの出力またはリリースダッシュボードから承認URLを開きます。承認アカウントにパスキーがまだない場合は登録し、権限の変更を確認し、リリースを承認または拒否します。

    Actionのデフォルト設定は、リリースがAwaiting approvalに達すると正常に返します。サービスワークフローはブラウザの決定を待ち続け、承認後に公開します。

リリースサービスが検証する内容

サービスはリリースを書き込む前に以下のチェックを完了します:

  1. GitHub OpenID Connect(OIDC)トークンが、承認されたリポジトリ、オーナー、ワークフロー、ref、環境、コミット、実行、GitHub ホステッドランナーを指定している。
  2. パッケージプロファイルが存在し、パブリッシャーによって署名され、委任リリース設定を含み、同じ正規GitHubリポジトリを指定している。
  3. 要求されたパッケージとバージョンがビルドされたプラグインバンドルと一致する。
  4. パッケージチェックサムがアップロードされたバイトと一致する。
  5. GitHub来歴が同じバンドル、リポジトリ、ワークフロー、コミット、実行をカバーしている。
  6. リリースレコードの宣言されたアクセスがバンドルマニフェストと一致する。
  7. バージョンレコードがまだ存在しない。
  8. 必要なパスキー承認が正確な検証結果と現在のプロファイルリビジョンをカバーしている。

Actionは各サービスコールに対して新しいGitHub OIDCトークンを要求します。バンドルと来歴ファイルはワークフローが承認された後にのみプライベート一時ストレージに入ります。サービスは検証済みのパッケージと画像のバイトをパブリッシャーのパーソナルデータサーバー(PDS)にアップロードし、そこでリリースレコードを作成し、不変のチェックサムアドレスURLを通じて検証済み来歴を公開します。

権限の境界

各認証情報には1つの役割があります:

認証情報使用者権限
ローカルCLI OAuthセッションemdash-plugin profile setupローカル確認後にパブリッシャー所有のパッケージプロファイルを作成または更新する。
GitHub OIDCトークンリリースActionサービスに対して1つのGitHubワークフロー実行を識別する。AT Protocolの書き込みアクセスは付与しない。
リリースサービス委任リリースサービスパッケージリリースレコードの作成と必要なBlobのアップロード。
パブリッシャーアプリケーションセッションリリースダッシュボードワークフロー接続の承認と委任公開の取り消し。
承認者セッションとパスキー承認ページチェックサムにバインドされた1つのリリース検証の承認または拒否。
Cloudflare Accessアイデンティティサービスオペレーターコンソールホステッドサービスの運用。パブリッシャーまたは承認者を表さない。

サービスはパブリッシャーと承認者の状態を別々に保存します。自分のリリースを表示するためにサインインしてもオペレーターアクセスは付与されず、オペレーターアイデンティティはパブリッシャーとしてリリースを承認できません。

Actionの動作

生成されたワークフローはapps/release-actionのActionを使用します。Actionはビルドされたバンドルと生のSigstore来歴、またはチェックサムにバインドされたHTTPSアーティファクトソースを含む互換性のあるrelease-fileを受け入れます。release-fileとバンドルまたは来歴入力を組み合わせないでください。

標準の生成されたワークフローは以下の入力を提供します:

入力
service-urlリリースサービスのHTTPSオリジン。
publisher-didパッケージプロファイルとリリースを所有するDID。
connection-invitation初回接続時のEMDASH_CONNECTION_INVITATION
bundle-fileemdash-plugin bundleが生成する単一のtarball。
provenance-fileactions/attest-build-provenanceからの生のbundle-path出力。

Actionは以下の出力を返します:

出力意味
connection-url初回実行時のワークフロー承認用ブラウザURL。
intent-idリリースインテント識別子。
statePublished、ターミナル、またはawaiting_approval状態。
approval-urlパスキー承認が必要な場合のブラウザURL。
release-uri公開されたリリースのAT URI。
release-cid公開されたリリースレコードのCID。
reason-codeターミナルインテントの安定した理由。

オプションの入力、カスタムURLソースワークフロー、ポーリング制御、正確な出力動作についてはActionリファレンスを参照してください。

トラブルシューティング

PACKAGE_PROFILE_REQUIRED

パッケージプロファイルが存在しない、委任リリース設定がない、非正規のリポジトリURLを使用している、またはGitHubワークフローとは異なるリポジトリを指定しています。

パブリッシャーアカウントでローカルにプロファイルセットアップを実行し、ワークフローを再開してください:

pnpm exec emdash-plugin profile setup

このチェックはサービスがバンドルまたは来歴のアップロードを受け入れる前に実行されます。

パブリックリポジトリが必要

GitHubはプライベートおよび内部リポジトリに対してプライベートSigstore信頼ルートを使用します。リリース検証者は現在、パブリックGitHub来歴のみを信頼しています。リリースワークフローをパブリックリポジトリに移動するか、emdash-plugin publishでローカルに公開してください。

招待の期限切れまたは無効

リリースダッシュボードで別の招待を作成し、EMDASH_CONNECTION_INVITATIONを置き換えてください。30分以内にワークフローを開始してください。招待はワンタイムで、1つのプラグインIDにスコープされています。

WORKLOAD_NOT_ALLOWED

GitHubリポジトリ、オーナー、ワークフローファイル、ref、または環境が承認済みワークフローポリシーと一致しません。リリースダッシュボードを開き、意図するスコープで新しいワークフロー接続を承認してください。

PROFILE_FETCH_FAILED

サービスがパブリッシャーのPDSからプロファイルを検証できませんでした。アカウントプロバイダーが利用可能になった後に再試行してください。プロファイルが削除または変更された場合はemdash-plugin profile setupを実行してください。

POLL_TIMEOUT

Actionがワークフロー承認、リリース承認、または公開が完了する前にtimeout-minutesに達しました。再実行する前にリリースダッシュボードでインテント状態を確認してください。同じGitHub Actions実行の再実行はそのべき等キーを再利用します。

自動公開の取り消し

リリースダッシュボードでTurn off automated publishingを選択します。取り消しにより保持されたリリース委任がクリアされます。既存のパッケージプロファイル、リリース、モデレーションラベル、インストール済みプラグイン、ダッシュボードログインは変更されません。

次の自動リリースの前に公開を再接続し、ワークフローを再度承認してください。

関連ドキュメント

  • Bundling and publishingはローカル公開とバンドル検証をカバーしています。
  • The plugin manifestはパッケージメタデータと宣言されたアクセスを定義しています。
  • Capabilities and securityはリリース承認とインストール時にレビューされる権限を説明しています。
  • The plugin registryは発見、モデレーション、インストール検証を説明しています。