Soumettez votre fichier manifeste au dépôt

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 :

1. Accédez à https://github.com/microsoft/winget-pkgs dans votre navigateur, puis sélectionnez Dupliquer.

2. À partir de l’invite de commandes Windows ou de PowerShell, utilisez la commande suivante pour cloner votre duplication.

   git clone --filter=blob:none --no-checkout <your-fork-name>
   

Étape 4 : Configurer l’extraction éparse

L’extraction partielle vous permet de choisir les parties d’un dépôt que vous souhaitez télécharger, au lieu de tout télécharger. À l’étape précédente, --filter=blob:none cela signifie que l’historique des validations n’a pas encore été téléchargé et --no-checkout qu’aucun fichier n’a encore été ajouté à la copie de travail (l’index).

Avant de télécharger quoi que ce soit, vous devez spécifier des filtres pour l'extraction éparse à utiliser (stockés dans .git/info/sparse-checkout).

Tout d’abord, voici une explication de ce qui va être mis en place. Vous devez ajouter vos fichiers manifestes au référentiel dans la structure de dossiers suivante :

manifeste / lettre / éditeur / 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.

Ainsi, pour configurer le checkout partiel pour tous les manifestes d’un éditeur, vous devez taper :

• Si vous utilisez Git version 2.37.0 ou ultérieure, exécutez la commande suivante pour configurer l’extraction éparse pour votre dossier.

  git sparse-checkout set manifests\<letter>\<publisher>
  

• Si vous utilisez une version antérieure de Git, reportez-vous à la documentation Git pour savoir comment configurer l’extraction éparse pour votre référentiel local.

Notez que la commande ci-dessus remplace tous les paramètres d’extraction éparses actuels et la configure pour un seul dossier, reportez-vous à la documentation Git pour la configuration de l’extraction éparse avec plusieurs dossiers.

Étape 5 : Extraire le référentiel

Vous pouvez maintenant appliquer les paramètres d’extraction éparse en effectuant la commande d’extraction classique.

git checkout

Même si le dossier que vous souhaitez soumettre n’a pas encore été validé dans le référentiel, vous devez toujours exécuter la commande de checkout, car il sera impossible d’ajouter (et donc de valider) quoi que ce soit sans les internes Git qu'il configure (l’index).

Si vous soumettez plusieurs propositions, créez une branche plutôt qu'un fork. Nous n’autorisons actuellement qu’un seul fichier manifeste par envoi.

git checkout -b <branch-name>

Étape 6 : Ajouter votre manifeste au référentiel local

Ajoutez vos fichiers dans le dossier indiqué (format expliqué à l’étape 4) : de manifestes / lettre / éditeur / application / version

Étape 7 : Envoyer votre manifeste au référentiel distant

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

1. 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
   

2. Utilisez la commande push pour envoyer (push) les modifications au dépôt distant.

   git push
   

Étape 8 : Créer une demande de fusion

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

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 en savoir plus sur les étiquettes et le processus, consultez la section Étiquettes de pull request 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 soumissions

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 pull request

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 (Pipeline Azure réussie)	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.
Problème Bloquant	Cette étiquette indique que la pull request 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.
Requiert-Une-Attention	Cette étiquette indique que la pull request doit être examinée par l’équipe de développement du Gestionnaire de packages Windows. Cela est dû soit à un échec au test qui nécessite un examen manuel, soit à un commentaire ajouté à la pull request par la communauté.
Besoin-de-retour-d'auteur	Indique qu’une erreur s’est produite lors de l’envoi. Nous allons vous renvoyer la pull request. Si vous ne résolvez pas le problème dans les 10 jours, le bot clôturera le pull request. Les étiquettes Needs-Author-Feedback sont généralement ajoutées quand la pull request a échoué et doit être mise à jour, ou si la personne qui examine la pull request a une question.
Validation-Completed (Validation-effectuée)	Indique que le passage de test a été complété avec succès et que votre pull request sera fusionnée.

Étiquettes d’erreur

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

Étiquette	Détails
Binary-Validation-Error (Erreur d'validation des 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.
Erreur-délai-expiration-analyse	Le test Binary-Validation-Test a dépassé le délai d’expiration. La pull request sera affectée à un ingénieur du Windows Package Manager pour être examinée.
Error-Hash-Mismatch (Erreur de non-correspondance du 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 pull request et réessayez.
Error-Installer-Availability (Erreur-disponibilité-installateur)	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 qu'il s'agit d'une erreur, ajoutez un commentaire : le pull request sera alors assigné à un ingénieur du Gestionnaire de packages Windows pour enquête.
manifest-Installer-Validation-Error	Incohérences ou valeurs absentes dans le manifeste pendant l’évaluation d’un package MSIX.
Manifest-Path-Error (Erreur de chemin du 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 soumettez à nouveau votre pull request.
Manifest-Validation-Error (Erreur de validation du 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 de Pull Request)	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 pull request pour résoudre le problème et réessayez.
Erreur-de-validation-d'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 requête 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	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 binaires ou envoyez-les pour analyse afin d’obtenir de l’assistance pour identifier 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	Le test a déterminé que le domaine de InstallerURL ne correspond pas au domaine attendu. Les politiques du Gestionnaire de packages Windows imposent que InstallerUrl vienne directement du lieu 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.
Erreur de 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 de hachage a échoué	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 personnalisée 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	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	L’URL ne provient pas directement du serveur de l'ISV. 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.
Erreur de validation et d'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. Veuillez régler le conflit de fusion et soumettre à nouveau votre pull request.
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 paquet pour y inclure les composants manquants ou ajoutez la dépendance au fichier manifeste, puis soumettez à nouveau la demande de fusion.
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 politiques du Gestionnaire de packages Windows imposent que InstallerUrl vienne directement du lieu de publication du fournisseur de logiciel indépendant.
Validation-échec-sans surveillance	Pendant l'installation, le test a dépassé le délai d'expiration. Ceci est probablement dû au fait que l'application ne s'installe pas de manière silencieuse. 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 pull request pour que les ingénieurs du Gestionnaire de paquets Windows s’occupent de l’investigation.
Erreur de validation de 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	Le package a une dépendance vis-à-vis du runtime C++ qui n’a pas pu être résolue. Mettez à jour le paquet pour y inclure les composants manquants ou ajoutez la dépendance au fichier manifeste, puis soumettez à nouveau la demande de fusion.

É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 Diffamatoire, calomnieux, injurieux et menaçant.
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 pull est attribuée aux ingénieurs du Gestionnaire de package Windows pour enquête.

É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'architectures)	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'architecture 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 requête 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.
Erreur interne	Un échec générique ou une erreur inconnue a été rencontré lors du cycle de test.

Erreur de validation des fichiers binaires

Si la validation de votre pull request échoue au test Analyse des installateurs et reçoit une étiquette Binary-Validation-Error, cela signifie que l'installation de votre application a échoué sur tous les environnements.

Test de scannage des installateurs

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 pull request est rejetée avec une étiquette Binary-Validation-Error.

Si vous obtenez une étiquette Binary-Validation-Error pour votre requête de tirage, mettez à jour votre logiciel pour supprimer le code détecté en tant qu'application potentiellement indésirable.

Parfois, les outils authentiques utilisés pour le débogage et les activités de bas niveau sont détectés comme logiciels potentiellement indésirables par les 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 pull request, procédez comme suit :

1. Un échec de pull request s’affiche en bas de la page web avec la chaîne Certaines vérifications ont échoué. Sélectionnez le lien Détails en regard d’une validation ayant échoué pour accéder à la page Azure Pipelines.

   

2. Sur la page Azure Pipelines, sélectionnez le lien 0 erreur/0 avertissement.

   

3. Sur la page suivante, sélectionnez le travail ayant échoué.

   

4. La page suivante affiche le résultat 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.