Envoyer votre manifeste au dépôt

Article
03/27/2023

Une fois que vous avez créé un manifeste de package qui décrit votre application, vous pouvez l’envoyer au dépôt du Gestionnaire de package Windows. Il s’agit d’un dépôt public qui contient une collection de manifestes accessibles par l’outil winget. Pour envoyer votre manifeste, vous devez le charger sur le dépôt open source https://github.com/microsoft/winget-pkgs sur GitHub.

Une fois que vous avez envoyé une demande de tirage (pull request) pour ajouter un nouveau manifeste au dépôt GitHub, un processus automatisé va valider votre fichier manifeste, et vérifier que le package est conforme aux stratégies du Gestionnaire de package Windows et n’est pas considéré comme malveillant. Si la validation réussit, votre package est ajouté au dépôt du Gestionnaire de package Windows public afin de pouvoir être découvert par l’outil client winget. Notez la distinction entre les manifestes du dépôt GitHub open source et le dépôt du Gestionnaire de package Windows public.

Important

Microsoft se réserve le droit de refuser tout envoi qu’elle qu’en soit la raison.

Validation du manifeste

Quand vous envoyez un manifeste au dépôt https://github.com/microsoft/winget-pkgs sur GitHub, votre manifeste est validé et évalué automatiquement pour la sécurité de l’écosystème Windows. Les manifestes peuvent également être examinés manuellement.

Pour plus d’informations sur le processus de validation, consultez la section Processus de validation ci-après.

Comment envoyer votre manifeste ?

Pour envoyer un manifeste au dépôt, effectuez les étapes suivantes.

Étape 1 : Valider votre manifeste

L’outil winget fournit la commande validate pour confirmer que vous avez créé votre manifeste correctement. Pour valider votre manifeste, utilisez cette commande.

winget validate \<path-to-the-manifests>

Si la validation échoue, utilisez les erreurs pour rechercher le numéro de ligne et apporter une correction. Une fois votre manifeste validé, vous pouvez l’envoyer au dépôt.

Étape 2 : Tester votre manifeste avec Bac à sable Windows

Le dépôt Gestionnaire de package Windows comprend un script qui installe le Gestionnaire de package Windows dans un bac à sable pour tester les soumissions de manifeste. Pour exécuter le script PowerShell, accédez à votre dépôt winget-pkgs. À partir de PowerShell, entrez la commande suivante :

powershell .\Tools\SandboxTest.ps1 manifests\m\Microsoft\VisualStudioCode\1.56.0

Vous devrez peut-être mettre à jour ce script avec le chemin correct de votre fichier manifeste : .\Tools\SandboxTest.ps1 <path to manifest or manifest folder>

Consultez le script de test de bac à sable complet dans le dépôt winget-pkgs.

Étape 3 : Cloner le dépôt

Pour créer une duplication (fork) du dépôt communautaire Gestionnaire de package Windows et cloner le dépôt sur votre ordinateur local :

Accédez à https://github.com/microsoft/winget-pkgs dans votre navigateur, puis sélectionnez Dupliquer.
À partir de l’invite de commandes Windows ou de PowerShell, utilisez la commande suivante pour cloner votre duplication.
```
git clone <your-fork-name>
```
Si vous entrez plusieurs envois, créez une branche plutôt qu’une duplication. Nous n’autorisons actuellement qu’un seul fichier manifeste par envoi.
```
git checkout -b <branch-name>
```

Étape 4 : Ajouter votre manifeste au dépôt local

Vous devez ajouter vos fichiers manifestes au dépôt dans la structure de dossiers suivante :

manifests / letter / publisher / application / version

Le dossier manifests est le dossier racine pour tous les manifestes du dépôt.
Le dossier letter correspond à la première lettre minuscule du nom de l’éditeur. Par exemple, m de l’éditeur Microsoft.
Le dossier publisher est le nom de la société qui publie le logiciel. Par exemple, Microsoft.
Le dossier application est le nom de l’application ou de l’outil. Par exemple, VSCode.
Le dossier version correspond à la version de l’application ou de l’outil. Par exemple, 1.0.0.

Les valeurs PackageIdentifier et PackageVersion du manifeste doivent correspondre à l’éditeur, au nom de l’application et à la version figurant dans le chemin du dossier du manifeste. Pour plus d’informations, consultez Créer votre manifeste de package.

Étape 5 : Envoyer votre manifeste vers le dépôt distant

Vous êtes maintenant prêt à envoyer votre nouveau manifeste vers le dépôt distant.

Utilisez la commande commit pour ajouter des fichiers ainsi que pour valider la modification et fournir des informations sur l’envoi.
```
git commit -m "Submitting ContosoApp version 1.0.0" --all
```
Utilisez la commande push pour envoyer (push) les modifications au dépôt distant.
```
git push
```

Étape 6 : Créer une demande de tirage

Une fois que vous avez envoyé vos modifications, revenez à https://github.com/microsoft/winget-pkgs et créez une demande de tirage pour fusionner votre duplication ou branche avec la branche principale.

screenshot of pull request tab

Processus d’envoi

Quand vous créez une demande de tirage, cette opération démarre un processus automatisé qui valide les manifestes et vérifie votre demande de tirage. Au cours de ce processus, nous allons exécuter des tests sur le programme d’installation et sur les fichiers binaires installés pour valider l’envoi.

Nous ajoutons des étiquettes à votre demande de tirage (pull request) pour vous permettre de suivre sa progression. Pour plus d’informations sur les étiquettes et le processus, consultez la section Étiquettes de demande de tirage ci-après.

Une fois l’opération terminée, votre envoi sera révisé manuellement par un modérateur et, une fois approuvée, votre application sera ajoutée au catalogue du Gestionnaire de package Windows.

Si une erreur se produit pendant le processus, vous en serez averti. En outre, nos étiquettes et notre bot vous aideront à résoudre le problème. Pour obtenir la liste des erreurs courantes, consultez la section Processus de validation ci-après.

Processus de validation

Quand vous créez une demande de tirage pour envoyer votre manifeste au dépôt du Gestionnaire de package Windows, cette opération démarre un processus automatisé qui valide le manifeste et traite votre demande de tirage. Les étiquettes GitHub sont utilisées pour partager la progression et pour vous permettre de communiquer avec nous.

Attentes concernant les envois

Tous les envois d’application au dépôt du Gestionnaire de package Windows doivent adhérer aux stratégies du dépôt du Gestionnaire de package Windows.

Attentes pour les soumissions :

Le manifeste est conforme aux spécifications du schéma.
Toutes les URL du manifeste mènent à des sites web sécurisés.
Le programme d’installation et l’application sont sans virus. Le package peut être identifié à tort comme étant un programme malveillant. Si vous pensez qu’il s’agit d’un faux positif, vous pouvez envoyer le programme d’installation à l’équipe Microsoft Defender pour analyse.
L’application s’installe et se désinstalle correctement pour les administrateurs et les non-administrateurs.
Le programme d’installation prend en charge les modes non interactifs.
Toutes les entrées du manifeste sont justes et sans équivoque.
Le programme d’installation provient directement du site web de l’éditeur.

Pour obtenir la liste complète des stratégies, consultez Stratégies du Gestionnaire de package Windows.

Étiquettes de demande de tirage

Lors de la validation, une série d’étiquettes est appliquée aux demandes de tirage pour indiquer la progression. Certaines étiquettes vous invitent à prendre des mesures, tandis que d’autres sont dirigées vers l’équipe d’ingénierie du Gestionnaire de package Windows.

Étiquettes d’état

Le tableau suivant décrit les étiquettes d’état que vous pouvez rencontrer.

Étiquette	Détails
Azure-Pipeline-Passed (Réussite-Azure-Pipeline)	Le manifeste a réussi au test. Il est en attente d’approbation. Si aucun problème n’est rencontré pendant le test, il sera automatiquement approuvé. Si un test échoue, il peut-être marqué pour révision manuelle.
Blocking-Issue (Problème-bloquant)	Cette étiquette indique que la demande de tirage ne peut pas être approuvée en raison d’un problème bloquant. Vous pouvez souvent savoir quel est le problème bloquant grâce à l’étiquette d’erreur incluse.
Needs-Attention	Cette étiquette indique que la demande de tirage doit être examinée par l’équipe de développement du Gestionnaire de package Windows. Ceci est dû à un échec au test qui nécessite une révision manuelle ou à un commentaire ajouté à la demande de tirage par la communauté.
Needs-Author-Feedback	Indique qu’une erreur s’est produite lors de l’envoi. Nous allons vous réaffecter la demande de tirage. Si vous ne résolvez pas le problème dans les 10 jours, le bot fermera la demande de tirage. Les étiquettes Needs-Author-Feedback sont généralement ajoutées en cas d’échec de la demande de tirage (pull request) qui doit être mise à jour, ou si la personne qui examine la demande de tirage a une question.
Validation-Completed (Validation-effectuée)	Indique que le test a été passé avec succès et que votre demande de tirage va être fusionnée.

Étiquettes d’erreur

Le tableau suivant décrit les étiquettes d’erreur que vous pouvez rencontrer. Les cas d’erreur ne vous seront pas tous affectés immédiatement. Certains peuvent déclencher une validation manuelle.

Étiquette	Détails
Binary-Validation-Error (Erreur-validation-fichiers binaires)	L’application incluse dans cette demande de tirage a échoué au test Analyse des programmes d’installation. Ce test est conçu pour vérifier que l’application s’installe sur tous les environnements sans avertissements. Pour plus d’informations sur cette erreur, consultez la section Erreurs de validation des fichiers binaires ci-après.
Error-Analysis-Timeout (Erreur-délai d’expiration-analyse)	Le test Binary-Validation-Test a dépassé le délai d’expiration. La demande de tirage sera affectée à un ingénieur de l’équipe du Gestionnaire de package Windows pour investigation.
Error-Hash-Mismatch (Erreur-non-correspondance-hachage)	Le manifeste envoyé n’a pas pu être traité, car le hachage InstallerSha256 fourni pour InstallerURL ne correspondait pas. Mettez à jour InstallerSha256 dans la demande de tirage, puis réessayez.
Error-Installer-Availability (Erreur-disponibilité-programme d’installation)	Le service de validation n’a pas pu télécharger le programme d’installation. Ceci peut être lié à des plages d’adresses IP Azure bloquées, ou l’URL du programme d’installation est peut-être incorrecte. Vérifiez que InstallerURL est correcte, puis réessayez. Si vous estimez que cette erreur n’en est pas une, ajoutez un commentaire : la demande de tirage sera alors affectée à un ingénieur de l’équipe du Gestionnaire de package Windows pour investigation.
Manifest-Installer-Validation-Error	Incohérences ou valeurs absentes dans le manifeste pendant l’évaluation d’un package MSIX.
Manifest-Path-Error (Erreur-chemin-manifeste)	Les fichiers manifeste doivent être placés dans une structure de dossiers spécifique. Cette étiquette indique un problème avec le chemin de votre envoi. Par exemple, la structure de dossiers n’a pas le format requis. Mettez à jour votre manifeste et votre chemin, puis renvoyez votre demande de tirage.
Manifest-Validation-Error (Erreur-validation-manifeste)	le manifeste envoyé contient une erreur de syntaxe. Résolvez le problème de syntaxe du manifeste, puis renvoyez-le. Pour plus d’informations sur le format et le schéma du manifeste, consultez le format requis.
PullRequest-Error (Erreur-demande de tirage)	La demande de tirage n’est pas valide, car tous les fichiers envoyés ne se trouvent pas dans le dossier des manifestes, ou il existe plusieurs packages ou versions dans la demande de tirage. Mettez à jour votre demande de tirage pour résoudre le problème et réessayez.
URL-Validation-Error (Erreur-validation-URL)	Le test de validation des URL n’a pas pu localiser l’URL et a répondu avec un code d’état d’erreur HTTP (403 ou 404), ou le test de réputation de l’URL a échoué. Vous pouvez identifier l’URL en question en examinant les détails de la vérification de la demande de tirage. Pour résoudre ce problème, mettez à jour les URL en question pour résoudre le code d’état d’erreur HTTP. Si le problème n’est pas dû à un code d’état d’erreur HTTP, vous pouvez envoyer l’URL pour examen afin d’éviter l’échec de réputation.
Validation-Defender-Error (Erreur-Validation-Defender)	Lors des tests dynamiques, Microsoft Defender a signalé un problème. Pour reproduire ce problème, installez votre application, puis exécutez une analyse Microsoft Defender complète. Si vous pouvez reproduire le problème, corrigez les fichiers binaires ou envoyez-les pour analyse afin d’obtenir de l’assistance sur ce faux positif. Si vous ne parvenez pas à reproduire le problème, ajoutez un commentaire pour que les ingénieurs de l’équipe du Gestionnaire de package Windows investiguent.
Validation-Domain (Validation-domaine)	Le test a déterminé que le domaine de InstallerURL ne correspond pas au domaine attendu. Les stratégies du Gestionnaire de package Windows imposent que InstallerUrl provienne directement de l’emplacement de publication du fournisseur de logiciel indépendant. Si vous pensez qu’il s’agit d’une fausse détection, ajoutez un commentaire à la demande de tirage pour que les ingénieurs de l’équipe du Gestionnaire de package Windows investiguent.
Validation-Error (Erreur-validation)	La validation du Gestionnaire de package Windows a échoué lors de l’approbation manuelle. Examinez le commentaire associé pour les étapes suivantes.
Validation-Executable-Error (Erreur-validation-exécutable)	Pendant le test de l’installation, le test n’a pas pu localiser l’application principale. Vérifiez que l’application s’installe correctement sur toutes les plateformes. Si votre application n’installe pas une application, mais qu’elle doit néanmoins être incluse dans le dépôt, ajoutez un commentaire à la demande de tirage pour que les ingénieurs de l’équipe du Gestionnaire de package Windows investiguent.
Validation-Hash-Verification-Failed (Validation-échec-vérification-hachage)	Lors du test de l’installation, l’installation de l’application échoue, car InstallerSha256 ne correspond plus au hachage de InstallerURL. Ceci peut se produire si l’application se trouve derrière une URL de redirection vers un microsite et que le programme d’installation a été mis à jour sans mettre à jour InstallerSha256. Pour résoudre ce problème, mettez à jour InstallerSha256 associé à InstallerURL et renvoyez.
Validation-HTTP-Error (Validation-erreur-HTTP)	L’URL utilisée pour le programme d’installation n’utilise pas le protocole HTTPS. Mettez à jour InstallerURL pour qu’elle utilise le protocole HTTPS et renvoyez la demande de tirage.
Validation-Indirect-URL (Validation-URL-indirecte)	L’URL ne provient pas directement du serveur du fournisseur de logiciel indépendant. Le test a déterminé qu’un redirecteur a été utilisé. Ceci n’est pas autorisé, car les stratégies du Gestionnaire de package Windows imposent que InstallerUrl provienne directement de l’emplacement de publication du fournisseur de logiciel indépendant. Supprimez la redirection et renvoyez.
Validation-Installation-Error (Validation-erreur-installation)	Lors de la validation manuelle de ce package, une erreur générale s’est produite. Examinez le commentaire associé pour les étapes suivantes.
Validation-Merge-Conflict (Validation-conflit-fusion)	Ce package n’a pas pu être validé en raison d’un conflit de fusion. Résolvez le conflit de fusion et renvoyez votre demande de tirage.
Validation-MSIX-Dependency (Validation-dépendance-MSIX)	Le package MSIX a une dépendance vis-à-vis d’un package qui n’a pas pu être résolue. Mettez à jour le package pour y inclure les composants manquants ou ajoutez la dépendance au fichier manifeste, puis renvoyez la demande de tirage.
Validation-Unapproved-URL (Validation-URL-non approuvée)	Le test a déterminé que le domaine de InstallerURL ne correspond pas au domaine attendu. Les stratégies du Gestionnaire de package Windows imposent que InstallerUrl provienne directement de l’emplacement de publication du fournisseur de logiciel indépendant.
Validation-Unattended-Failed (Échec-validation-sans assistance)	Pendant l’installation, le test dépassé le délai d’expiration. Ceci est probablement dû au fait que l’application ne s’installe pas en mode silencieux. Cela peut également être dû à une autre erreur et à l’arrêt du test. Vérifiez que vous pouvez installer votre manifeste sans entrée de l’utilisateur. Si vous avez besoin d’assistance, ajoutez un commentaire à la demande de tirage pour que les ingénieurs de l’équipe du Gestionnaire de package Windows investiguent.
Validation-Uninstall-Error (Validation-erreur-désinstallation)	Lors du test de la désinstallation, l’application n’a pas été nettoyée complètement après désinstallation. Examinez le commentaire associé pour plus d’informations.
Validation-VCRuntime-Dependency (Validation-dépendance-VCRuntime)	Le package a une dépendance vis-à-vis du runtime C++ qui n’a pas pu être résolue. Mettez à jour le package pour y inclure les composants manquants ou ajoutez la dépendance au fichier manifeste, puis renvoyez la demande de tirage.

Étiquettes de stratégie de contenu

Le tableau suivant liste les étiquettes de stratégie de contenu. Si une de ces étiquettes est ajoutée, cela signifie que quelque chose dans les métadonnées du manifeste a déclenché une révision manuelle supplémentaire du contenu pour vérifier que les métadonnées suivent les stratégies du Gestionnaire de package Windows.

Étiquette	Détails
Policy-Test-2.1 (Stratégie-test-2.1)	ConsultezSpécifications générales pour le contenu.
Policy-Test-2.2 (Stratégie-test-2.2)	Consultez Contenu comportant des noms ou des logos d’origine ou de tiers.
Policy-Test-2.3 (Stratégie-test-2.3)	Consultez Risque de dommages.
Policy-Test-2.4 (Stratégie-test-2.4)	Consultez Propos diffamatoires, calomnieux et menaçants.
Policy-Test-2.5 (Stratégie-test-2.5)	Consultez Contenu offensant.
Policy-Test-2.6 (Stratégie-test-2.6)	Consultez Alcool, tabac, armes et drogues.
Policy-Test-2.7 (Stratégie-test-2.7)	Consultez Contenu pour adultes.
Policy-Test-2.8 (Stratégie-test-2.8)	Consultez Activité illégale.
Policy-Test-2.9 (Stratégie-test-2.9)	Consultez Propos blasphématoires excessifs et contenu inapproprié.
Policy-Test-2.10 (Stratégie-test-2.10)	Consultez Spécifications propres à certains pays/certaines régions.
Policy-Test-2.11 (Stratégie-test-2.11)	Consultez Évaluations de l’âge.
Policy-Test-2.12 (Stratégie-test-2.12)	Consultez Contenu généré par l’utilisateur.

Étiquettes internes

Le tableau suivant liste les étiquettes d’erreur interne. Quand des erreurs internes se produisent, votre demande de tirage est affectée aux ingénieurs de l’équipe du Gestionnaire de package Windows pour investigation.

Étiquette	Détails
Internal-Error-Domain (Erreur-interne-domaine)	Une erreur s’est produite lors de la validation du domaine de l’URL.
Internal-Error-Dynamic-Scan(Erreur-interne-analyse dynamique)	Une erreur s’est produite lors de la validation des fichiers binaires installés.
Internal-Error-Keyword-Policy (Erreur-interne-stratégie-mot clé)	Une erreur s’est produite lors de la validation du manifeste.
Internal-Error-Manifest (Erreur-interne-manifeste)	Une erreur s’est produite lors de la validation du manifeste.
Internal-Error-NoArchitectures (Erreur-interne-pas d’achitecture)	Une erreur s’est produite, car le test n’a pas pu déterminer l’architecture de l’application.
Internal-Error-NoSupportedArchitectures (Erreur-interne-pas d’achitecture prise en charge)	Une erreur s’est produite, car l’architecture actuelle n’est pas prise en charge.
Internal-Error-PR (Erreur-interne-demande de tirage)	Une erreur s’est produite au cours du traitement de la demande de tirage.
Internal-Error-Static-Scan (Erreur-interne-analyse-statique)	Une erreur s’est produite lors de l’analyse statique des programmes d’installation.
Internal-Error-URL (Erreur-interne-URL)	Une erreur s’est produite lors de la validation de la réputation des programmes d’installation.
Internal-Error (Erreur-interne)	Un échec générique ou une erreur inconnue qui a eu lieu lors de la passe de test.

Erreur de validation des fichiers binaires

Si la validation de votre demande de tirage échoue au test Analyse des programmes d’installation et reçoit une étiquette Binary-Validation-Error, cela indique que l’installation de votre application a échoué sur tous les environnements.

Test Analyse des programmes d’installation

Pour offrir une excellente expérience utilisateur d’installation d’application, le Gestionnaire de package Windows doit s’assurer que toutes les applications s’installent sur des PC sans erreur, quel que soit l’environnement. Un test clé consiste à s’assurer que toutes les applications s’installent sans avertissements sur diverses configurations antivirus populaires. Windows fournit le programme antivirus Microsoft Defender intégré, mais de nombreux clients et utilisateurs d’entreprise utilisent d’autres logiciels antivirus.

Chaque envoi au Référentiel de package Windows passe à travers plusieurs programmes antivirus. Ces programmes ont tous des algorithmes de détection de virus différents pour identifier les applications potentiellement indésirables et les programmes malveillants.

Gérer les erreurs de validation binaire

En cas d’échec de la validation d’une application, Microsoft tente d’abord de vérifier auprès des fournisseurs d’antivirus si le logiciel indiqué n’est pas un faux positif. Dans de nombreux cas, après notification et validation, le fournisseur de l’antivirus met à jour son algorithme, à la suite de quoi l’application réussit le test.

Dans certains cas, le fournisseur antivirus ne peut pas déterminer si l’anomalie de code détectée est un faux positif. Dans ce cas, l’application ne peut pas être ajoutée au référentiel Gestionnaire de package Windows. La demande de tirage est rejetée avec une étiquette Binary-Validation-Error.

Si vous obteniez une étiquette Binary-Validation-Error pour votre demande de tirage, mettez à jour votre logiciel pour supprimer le code détecté comme étant une application potentiellement indésirable.

Parfois, les outils authentiques utilisés pour le débogage et les activités de bas niveau apparaissent en tant qu’applications potentiellement indésirables aux logiciels antivirus. C’est dû au fait que le code de débogage nécessaire a une signature similaire à celle de logiciels indésirables. Même si cette pratique de codage est légitime, le référentiel Gestionnaire de package Windows ne peut malheureusement pas autoriser ces applications.

Résolution des problèmes liés à la soumission

Si la soumission pour le Gestionnaire de package Windows échoue, vous pouvez utiliser les étiquettes décrites ci-dessus afin d’examiner la raison de l’échec.

Pour examiner les échecs de demande de tirage, procédez comme suit :

Un échec de demande de tirage s’affiche en bas de la page web avec la chaîne Certaines vérifications n’ont pas réussi. Sélectionnez le lien Détails en regard d’une validation ayant échoué pour accéder à la page Azure Pipelines.
Sur la page Azure Pipelines, sélectionnez le lien 0 erreur/0 avertissement.
Sur la page suivante, sélectionnez le travail ayant échoué.
La page suivante affiche la sortie du travail ayant échoué. La sortie doit vous aider à identifier la modification à apporter pour corriger le manifeste.

Dans l’exemple suivant, l’échec s’est produit pendant la tâche Validation de l’installation.