リポジトリにマニフェストを送信する
アプリケーションを記述するパッケージ マニフェストを作成したら、マニフェストを Windows パッケージ マネージャー リポジトリに送信する準備ができています。 これは、winget ツールがアクセスできるマニフェストのコレクションを含む公開リポジトリです。 マニフェストを送信するには、GitHub のオープン ソース https://github.com/microsoft/winget-pkgs リポジトリにアップロードします。
プル要求を送信して GitHub リポジトリに新しいマニフェストを追加すると、自動プロセスによってマニフェスト ファイルが検証され、パッケージが Windows パッケージ マネージャー ポリシーに準拠し、既知の悪意のあるものではないことが確認されます。 この検証が成功すると、パッケージは公開されている Windows パッケージ マネージャー リポジトリに追加されるため、winget クライアント ツールで検出できるようになります。 オープン ソースの GitHub リポジトリのマニフェストと、公開されている Windows パッケージ マネージャー リポジトリの違いに注意してください。
重要
Microsoft は、任意の理由で送信を拒否する権利を留保します。
マニフェストの検証
GitHub の https://github.com/microsoft/winget-pkgs リポジトリにマニフェストを送信すると、マニフェストが Windows エコシステムの安全性に関して自動的に検証および評価されます。 マニフェストは手動で確認される場合もあります。
検証プロセスの詳細については、以下の「検証プロセス」セクションを参照してください。
マニフェストの送信方法
マニフェストをリポジトリに送信するには、次の手順を実行します。
手順 1:マニフェストを検証する
winget tool では、マニフェストが正しく作成されたことを確認するための validate コマンドが提供されています。 マニフェストを検証するには、このコマンドを使用します。
winget validate \<path-to-the-manifests>
検証が失敗した場合は、エラーを使用して行番号を特定し、修正を行います。 マニフェストが検証されたら、それをリポジトリに送信できます。
手順 2: Windows サンドボックスを使用してマニフェストをテストする
Windows パッケージ マネージャー リポジトリには、マニフェストの送信をテストするためにサンドボックスに Windows パッケージ マネージャーをインストールするスクリプトが含まれています。 powershell スクリプトを実行するには、winget-pkgs リポジトリに移動します。 PowerShell から以下のコマンドを入力します。
powershell .\Tools\SandboxTest.ps1 manifests\m\Microsoft\VisualStudioCode\1.56.0
マニフェスト ファイルへの正しいパス .\Tools\SandboxTest.ps1 <path to manifest or manifest folder> を指定してこのスクリプトを更新する必要がある場合があります。
winget-pkgs リポジトリの完全なサンドボックス テスト スクリプトを参照してください。
手順 3: リポジトリを複製する
Windows パッケージ マネージャー コミュニティ リポジトリのフォークを作成し、リポジトリをローカル コンピューターに複製するには、以下を実行します。
ブラウザーで https://github.com/microsoft/winget-pkgs にアクセスし、[Fork] (フォーク) を選択します。
Windows コマンド プロンプトや PowerShell から、次のコマンドを使用してフォークを複製します。
git clone <your-fork-name>複数の送信を入力する場合は、フォークではなくブランチを作成します。 現在、送信ごとに 1 つのマニフェスト ファイルのみが許可されます。
git checkout -b <branch-name>
手順 4: ローカル リポジトリにマニフェストを追加する
次のフォルダー構造で、リポジトリにマニフェスト ファイルを追加する必要があります。
manifests / letter / publisher / application / version
- manifests フォルダーは、リポジトリ内のすべてのマニフェストのルート フォルダーです。
- letter フォルダーは、発行元の名前の最初の文字 (小文字) です。 発行元「Microsoft」の m などです。
- publisher フォルダーは、ソフトウェアを発行する会社の名前です。 たとえば、Microsoft です。
- application フォルダーは、アプリケーションまたはツールの名前です。 たとえば、VSCode です。
- version フォルダーは、アプリケーションまたはツールのバージョンです。 たとえば、1.0.0 のようになります。
マニフェスト内の PackageIdentifier および PackageVersion 値は、マニフェスト フォルダー パス内の発行元、アプリケーションの名前とバージョンと一致する必要があります。 詳しくは、「パッケージ マニフェストを作成する」をご覧ください。
手順 5: リモート リポジトリにマニフェストを送信する
これで、リモート リポジトリに新しいマニフェストをプッシュする準備ができました。
commitコマンドを使用して、ファイルの追加や変更のコミットを行い、送信に関する情報を指定します。git commit -m "Submitting ContosoApp version 1.0.0" --allpushコマンドを使用して、リモート リポジトリに変更をプッシュします。git push
手順 6: pull request を作成する
変更をプッシュした後、https://github.com/microsoft/winget-pkgs に戻り、フォークまたはブランチをメイン ブランチにマージする pull request を作成します。
送信プロセス
プル要求を作成すると、マニフェストを検証してプル要求を確認する自動プロセスが開始されます。 このプロセスの間に、インストーラーとインストール済みバイナリのテストが実行されて、申請が検証されます。
pull request にラベルが追加され、その進行状況を追跡できるようになります。 ラベルとプロセスの詳細については、以下の「プル要求のラベル」セクションを参照してください。
完了すると、提出物がモデレーターにより手動でレビューされ、それが承認されると、申請が Windows パッケージ マネージャー カタログに追加されます。
プロセスの間にエラーが発生した場合は、発行元に通知が送られ、ラベルとボットによって申請の修正がサポートされます。 一般的なエラーの一覧については、以下の「検証プロセス」セクションを参照してください。
検証プロセス
マニフェストを Windows パッケージ マネージャー リポジトリに申請するためのプル要求を作成すると、マニフェストを検証してプル要求を処理する自動プロセスが開始されます。 GitHub ラベルは、進行状況を共有し、申請者と Microsoft が情報を交換できるようにするために使用されます。
送信の必要事項
Windows パッケージ マネージャー リポジトリへのすべてのアプリケーション申請は、Windows パッケージ マネージャー リポジトリ ポリシーに準拠している必要があります。
送信の必要事項:
- マニフェストは、スキーマの要件に準拠していること。
- マニフェスト内のすべての URL は、安全な Web サイトにつながること。
- インストーラーとアプリケーションは、ウイルスに感染していないこと。 パッケージは、誤ってマルウェアとして識別される場合があります。 偽陽性であると思われる場合は、分析のためにインストーラーを Microsoft Defender チームに送信することができます。
- 管理者と非管理者の両方に対して、アプリケーションが正しくインストールされ、アンインストールされること。
- インストーラーは非対話型モードをサポートしていること。
- すべてのマニフェスト エントリは正確で、誤解を招くことがないこと。
- インストーラーは、発行元の Web サイトから直接取得されること。
ポリシーの完全な一覧については、Windows パッケージ マネージャー ポリシーに関する記事を参照してください。
プル要求のラベル
検証の間に、進行状況を伝えるための一連のラベルがプル要求に適用されます。 ラベルには、アクションの実行を指示するものと、Windows パッケージ マネージャー エンジニアリング チームに誘導するものがあります。
状態ラベル
次の表は、表示される可能性のある状態ラベルの説明です。
| Label | 詳細 |
|---|---|
| Azure-Pipeline-Passed | マニフェストのテスト パスが完了しました。 承認を待っています テスト パスの間に問題が発生しなかった場合は、自動的に承認されます。 テストが失敗した場合は、手動レビューのフラグが設定されている可能性があります。 |
| Blocking-Issue (障害となっている問題) | このラベルは、障害となっている問題があるため、プル要求を承認できないことを示します。 多くの場合、障害となっている問題は、含まれているエラー ラベルによってわかります。 |
| Needs-Attention (注意が必要) | このラベルは、Windows パッケージ マネージャー開発チームがプル要求を調査する必要があることを示します。 これは、手動レビューが必要なテスト失敗、またはコミュニティによってプル要求に追加されたコメントが原因です。 |
| Needs-Author-Feedback | 申請に問題があることを示します。 プル要求は申請者に再度割り当てられます。 申請者が 10 日以内に問題に対処しない場合、プル要求はボットによって終了されます。 Needs-Author-Feedback (作成者のフィードバックが必要) ラベルは、通常、更新する必要がある問題がプル要求にあった場合、またはプル要求のレビュー担当者からの質問がある場合に追加されます。 |
| Validation-Completed (検証完了) | テスト パスが正常に完了し、プル要求がマージされることを示します。 |
エラー ラベル
次の表は、表示される可能性のあるエラー ラベルの説明です。 すべてのエラー ケースがすぐに割り当てられるわけではありません。 手動による検証をトリガーするものがあります。
| Label | 詳細 |
|---|---|
| Binary-Validation-Error (バイナリ検証エラー) | このプル要求に含まれるアプリケーションは、インストーラー スキャン テストに合格しませんでした。 このテストは、アプリケーションが警告なしですべての環境にインストールされることを確認するように設計されています。 このエラーの詳細については、以下の「バイナリ検証エラー」セクションを参照してください。 |
| Error-Analysis-Timeout (分析タイムアウト エラー) | Binary-Validation-Testテストがタイムアウトしました。プル要求は、調査のために Windows パッケージ マネージャー エンジニアに割り当てられます。 |
| Error-Hash-Mismatch (ハッシュ不一致エラー) | InstallerURL に指定された InstallerSha256 ハッシュが一致しないため、申請されたマニフェストを処理できませんでした。 プル要求の InstallerSha256 を更新してから、操作をやり直してください。 |
| Error-Installer-Availability (インストーラー使用可能性エラー) | 検証サービスでインストーラーをダウンロードできませんでした。 これは、Azure IP 範囲がブロックされていることに関連しているか、またはインストーラーの URL が正しくない可能性があります。 InstallerURL が正しいことを確認し、もう一度やり直してください。 申請者がこの不合格は誤りであると考える場合は、コメントを追加してください。プル要求は、調査のために Windows パッケージ マネージャー エンジニアに割り当てられます。 |
| Manifest-Installer-Validation-Error | MSIX パッケージの評価中に、マニフェストの不整合または存在しない値がありました。 |
| Manifest-Path-Error (マニフェスト パス エラー) | マニフェスト ファイルは、特定のフォルダー構造に配置されている必要があります。 このラベルは、申請のパスに問題があることを示します。 たとえば、フォルダー構造に必要な形式がありません。 マニフェストとパスを更新して、プル要求を再申請してください。 |
| Manifest-Validation-Error (マニフェスト検証エラー) | 送信されたマニフェストに構文エラーが含まれています。 マニフェストに関する構文の問題に対処し、再申請してください。 マニフェストの形式とスキーマの詳細については、必要な形式に関する記事を参照してください。 |
| PullRequest-Error (プル要求エラー) | 申請されたファイルでマニフェスト フォルダーに格納されていないものがあるため、またはプル要求に複数のパッケージまたはバージョンがあるために、プル要求が無効です。 プル要求を更新して問題に対処してから、もう一度試してください。 |
| URL-Validation-Error (URL 検証エラー) | URL 検証テストで URL が見つからず、HTTP エラー状態コード (403 または 404) で応答したか、または URL 評価テストに失敗しました。 問題のある URL は、プル要求チェックの詳細を調べることでわかります。 この問題に対処するには、問題の URL を更新して HTTP エラー状態コードを解決します。 問題の原因が HTTP エラー状態コードでない場合は、評価の失敗を回避するためのレビュー用に URL を申請することができます。 |
| Validation-Defender-Error (検証 Defender エラー) | 動的テストの間に、Microsoft Defender によって問題が報告されました。 この問題を再現するには、アプリケーションをインストールした後、Microsoft Defender でフル スキャンを実行します。 問題を再現できる場合は、バイナリを修正するか、偽陽性のサポートのための分析用に申請してください。 問題を再現できない場合は、コメントを追加して、Windows パッケージ マネージャー エンジニアに調査を依頼します。 |
| Validation-Domain (検証ドメイン) | InstallerURL が予期されるドメインと一致しない場合、テストによってドメインが特定されました。 Windows パッケージ マネージャー ポリシーでは、InstallerUrl は ISV のリリース場所から直接取得されている必要があります。 この検出が誤っていると思われる場合は、プル要求にコメントを追加して、Windows パッケージ マネージャー エンジニアに調査を依頼します。 |
| Validation-Error (検証エラー) | 手動承認において、Windows パッケージ マネージャーの検証が失敗しました。 次の手順については、付随するコメントを参照してください。 |
| Validation-Executable-Error (実行可能ファイル検証エラー) | インストール テストの間に、テストでプライマリ アプリケーションを見つけることができませんでした。 すべてのプラットフォームでアプリケーションが正しくインストールされることを確認してください。 アプリケーションがインストールされなくても、リポジトリに含まれている必要がある場合は、プル要求にコメントを追加して、Windows パッケージ マネージャー エンジニアに調査を依頼します。 |
| Validation-Hash-Verification-Failed (ハッシュ検証失敗) | インストール テストの間に、InstallerSha256 が InstallerURL ハッシュと一致しなくなったため、アプリケーションをインストールできません。 これは、アプリケーションがバニティ URL の内側にあり、インストーラーが InstallerSha256 を更新することなく更新された場合に、発生する可能性があります。 この問題に対処するには、InstallerURL に関連付けられている InstallerSha256 を更新して、もう一度申請します。 |
| Validation-HTTP-Error (HTTP 検証エラー) | インストーラーに使用される URL で、HTTPS プロトコルが使用されていません。 HTTPS を使用するように InstallerURL を更新して、プル要求を再申請します。 |
| Validation-Indirect-URL (間接 URL 検証) | URL が ISV サーバーから直接取得されていません。 テストにより、リダイレクターが使用されたことがわかりました。 Windows パッケージ マネージャー ポリシーでは、InstallerUrl は ISV のリリース場所から直接取得される必要があるため、これは許可されません。 リダイレクトを削除して、再申請します。 |
| Validation-Installation-Error (インストール検証エラー) | このパッケージの手動検証中に、一般的なエラーが発生しました。 次の手順については、付随するコメントを参照してください。 |
| Validation-Merge-Conflict (マージ競合検証) | マージの競合が原因で、このパッケージを検証できません。 マージの競合に対処して、プル要求を再申請してください。 |
| Validation-MSIX-Dependency (MSIX 依存関係検証) | MSIX パッケージに、解決できないパッケージへの依存関係があります。 足りないコンポーネントを含むようにパッケージを更新するか、依存関係をマニフェスト ファイルに追加してから、プル要求を再申請してください。 |
| Validation-Unapproved-URL (未承認 URL 検証) | InstallerURL が予期されるドメインと一致しない場合、テストによってドメインが特定されました。 Windows パッケージ マネージャー ポリシーでは、InstallerUrl は ISV のリリース場所から直接取得されている必要があります。 |
| Validation-Unattended-Failed (無人検証失敗) | インストール中に、テストがタイムアウトしました。可能性が最も高い原因は、アプリケーションがサイレントでインストールされないことです。 また、他のエラーが発生して、テストが停止した可能性もあります。 ユーザー入力なしでマニフェストをインストールできることを確認します。 サポートが必要な場合は、プル要求にコメントを追加すると、Windows パッケージ マネージャー エンジニアが調査します。 |
| Validation-Uninstall-Error (アンインストール検証エラー) | アンインストール テストにおいて、アンインストール後にアプリケーションが完全にクリーンアップされませんでした。 詳細については、付随するコメントを参照してください。 |
| Validation-VCRuntime-Dependency (VCRuntime 依存関係検証) | パッケージに、解決できない C++ ランタイムへの依存関係があります。 足りないコンポーネントを含むようにパッケージを更新するか、依存関係をマニフェスト ファイルに追加してから、プル要求を再申請してください。 |
コンテンツ ポリシー ラベル
次の表に、コンテンツ ポリシー ラベルの一覧を示します。 これらのラベルのいずれかが追加された場合、マニフェスト メタデータ内の何かにより、メタデータが Windows パッケージ マネージャー ポリシーに従っていることを確認するための、追加の手動コンテンツ レビューがトリガーされました。
| Label | 詳細 |
|---|---|
| Policy-Test-2.1 (ポリシー テスト 2.1) | 「コンテンツの全般的要件」を参照してください。 |
| Policy-Test-2.2 (ポリシー テスト 2.2) | 「名前、ロゴを含む、オリジナルおよび第三者のコンテンツ」を参照してください。 |
| Policy-Test-2.3 (ポリシー テスト 2.3) | 「損害のリスク」を参照してください。 |
| Policy-Test-2.4 (ポリシー テスト 2.4) | 「誹謗中傷や威嚇」を参照してください。 |
| Policy-Test-2.5 (ポリシー テスト 2.5) | 「不快なコンテンツ」を参照してください。 |
| Policy-Test-2.6 (ポリシー テスト 2.6) | 「アルコール、タバコ、武器、および麻薬」を参照してください。 |
| Policy-Test-2.7 (ポリシー テスト 2.7) | 「成人向けコンテンツ」を参照してください。 |
| Policy-Test-2.8 (ポリシー テスト 2.8) | 「違法行為」を参照してください。 |
| Policy-Test-2.9 (ポリシー テスト 2.9) | 「過度の冒とくおよび不適切なコンテンツ」を参照してください。 |
| Policy-Test-2.10 (ポリシー テスト 2.10) | 「国または地域特有の要件」を参照してください。 |
| Policy-Test-2.11 (ポリシー テスト 2.11) | 「年齢区分」を参照してください。 |
| Policy-Test-2.12 (ポリシー テスト 2.12) | 「ユーザー生成コンテンツ」を参照してください。 |
内部ラベル
次の表は、内部エラー ラベルの一覧です。 内部エラーが発生すると、プル要求は Windows パッケージ マネージャー エンジニアによる調査に割り当てられます。
| Label | 詳細 |
|---|---|
| Internal-Error-Domain (ドメイン内部エラー) | URL のドメイン検証中にエラーが発生しました。 |
| Internal-Error-Dynamic-Scan (動的スキャン内部エラー) | インストール済みバイナリの検証中にエラーが発生しました。 |
| Internal-Error-Keyword-Policy (キーワード ポリシー内部エラー) | マニフェストの検証中にエラーが発生しました。 |
| Internal-Error-Manifest (マニフェスト内部エラー) | マニフェストの検証中にエラーが発生しました。 |
| Internal-Error-NoArchitectures (アーキテクチャ不明内部エラー) | アプリケーションの場合、テストでアーキテクチャを特定できないためにエラーが発生しました。 |
| Internal-Error-NoSupportedArchitectures (アーキテクチャ非サポート内部エラー) | 現在のアーキテクチャがサポートされていないため、エラーが発生しました。 |
| Internal-Error-PR (PR 内部エラー) | プル要求の処理中にエラーが発生しました。 |
| Internal-Error-Static-Scan (静的スキャン内部エラー) | インストーラーの静的分析中にエラーが発生しました。 |
| Internal-Error-URL (URL 内部エラー) | インストーラーの評価検証中にエラーが発生しました。 |
| Internal-Error (内部エラー) | テスト パスの間に、一般的なエラーまたは不明なエラーが発生しました。 |
バイナリ検証エラー
プル要求の検証でインストーラー スキャン テストが不合格になり、Binary-Validation-Error ラベルを受信した場合は、アプリケーションをすべての環境にインストールできなかったことを意味します。
インストーラー スキャン テスト
アプリケーション インストールの優れたユーザー エクスペリエンスを提供するために、Windows パッケージ マネージャーは、環境に関係なく、すべてのアプリケーションがエラーなしで PC にインストールされることを確認する必要があります。 1 つの重要なテストは、すべてのアプリケーションが、さまざまな一般的なウイルス対策構成の警告なしでインストールされるようにすることです。 Windows には組み込みの Microsoft Defender ウイルス対策プログラムが用意されていますが、多くの企業のお客様やユーザーは他のウイルス対策ソフトウェアを使用しています。
Windows パッケージ マネージャーへの各送信は、複数のウイルス対策プログラムを介して実行されます。 これらのすべてのプログラムには、望ましくない可能性があるアプリケーション (PUA) とマルウェアを識別するための、さまざまなウイルス検出アルゴリズムが備わっています。
バイナリ検証エラーに対処する
アプリケーションが検証に合格しなかった場合、Microsoft はまず、フラグを付けられたソフトウェアが誤検知でないかどうかを、ウイルス対策ベンダーに対して確認します。 多くの場合、通知と検証が行われた後、ウイルス対策ベンダーがアルゴリズムを更新し、アプリケーションは合格します。
場合によっては、ウイルス対策ベンダーは、検出されたコードの異常が誤検知であるかどうかを判断できません。 この場合、そのアプリケーションを Windows パッケージ マネージャー リポジトリに追加することはできません。 Pull Request は、Binary-Validation-Error ラベルで拒否されます。
Pull Request で Binary-Validation-Error ラベルが発生した場合は、ソフトウェアを更新し、PUA として検出されたコードを削除してください。
場合によっては、デバッグや低レベル アクティビティに使用される正規のツールであっても、ウイルス対策ソフトウェアに PUA として認識されることがあります。 これは、必要なデバッグ コードに、望ましくないソフトウェアと類似するシグネチャが含まれているためです。 このコーディング方法は正当なものですが、残念ながら Windows パッケージ マネージャー リポジトリはこれらのアプリケーションを許可できません。
送信のトラブルシューティング
Windows パッケージ マネージャーの送信が失敗した場合は、上記のラベルを使用して、エラーの原因を調査できます。
Pull Request のエラーを調査するには、次の手順を実行します。
Pull Request のエラーが「一部のチェックが失敗しました」という文字列とともに Web ページの下部に表示されます。 失敗した検証の横にある [詳細] リンクを選択して、[Azure Pipelines] ページに移動します。
[Azure Pipelines] ページで、[0 エラー/ 0 警告] リンクを選択します。
次のページで、失敗したジョブを選択します。
次のページに、失敗したジョブの出力が表示されます。 出力は、マニフェストを修正するためにどのような変更が必要かを特定するうえで役立ちます。
次の例では、Installation Validation タスクの際に処理が失敗しています。
Windows developer
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示