Отправка манифеста в репозиторий

После создания манифеста пакета, который описывает приложение, вы можете отправить манифест в репозиторий Диспетчера пакетов Windows. Это общедоступный репозиторий, содержащий коллекцию манифестов, к которым может получить доступ инструмент winget . Чтобы отправить манифест, передайте его в репозиторий с открытым исходным кодом https://github.com/microsoft/winget-pkgs на сайте GitHub.

После того как вы отправите запрос на вытягивание для добавления нового манифеста в репозиторий GitHub, автоматизированный процесс проверит ваш файл манифеста и убедится, что пакет соответствует политикам Диспетчера пакетов Windows и не является известным как вредоносный. Если проверка прошла успешно, пакет будет добавлен в общедоступный репозиторий Диспетчера пакетов Windows, чтобы его можно было обнаружить с помощью клиентской программы winget. Обратите внимание на различие между манифестами в репозитории GitHub с открытым исходным кодом и в общедоступном репозитории Диспетчера пакетов Windows.

Внимание

Корпорация Майкрософт оставляет за собой право отказаться от отправки по любой причине.

Проверка манифеста

При отправке манифеста в репозиторий https://github.com/microsoft/winget-pkgs на сайте GitHub манифест будет автоматически проверен и оцениваться для обеспечения безопасности экосистемы Windows. Манифесты также могут быть просмотрены вручную.

Дополнительные сведения о процессе проверки см. в разделе "Процесс проверки" ниже.

Как отправить манифест

Чтобы отправить манифест в репозиторий, выполните следующие действия.

Шаг 1. Проверка манифеста

В программе winget предусмотрена команда validate, позволяющая убедиться в правильности созданного манифеста. Используйте эту команду, чтобы проверить манифест.

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

Если проверка завершается сбоем, воспользуйтесь сообщениями об ошибках, чтобы узнать номер строки и внести исправление. После проверки манифеста его можно отправить в репозиторий.

Шаг 2. Проверка манифеста с использованием Windows Sandbox

Репозиторий Диспетчера пакетов 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 и клонировать репозиторий на локальный компьютер:

1. Перейдите https://github.com/microsoft/winget-pkgs в браузер и выберите "Форк".

2. В командной строке Windows или PowerShell используйте следующую команду, чтобы клонировать форк вашего репозитория.

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

Шаг 4. Настройка разреженной выборки

Разреженная выборка позволяет выбрать, какие части репозитория вы хотите скачать, вместо того чтобы загружать все. На предыдущем шаге, --filter=blob:none означает, что журнал фиксации еще не скачан, а --no-checkout означает, что файлы еще не добавлены в рабочую копию (индекс).

Прежде чем загружать что-либо, необходимо указать фильтры для разреженного извлечения, которые использовать (которые хранятся в .git/info/sparse-checkout).

Сначала, вот описание того, что будет установлено. Файлы манифеста необходимо добавить в репозиторий в следующей структуре папок:

манифесты / письмо / издатель / приложение / версия

• Папка manifests является корневой для всех манифестов в репозитории.
• Папка буква — это первая буква названия издателя в нижнем регистре. Например, на примере использования буквы m от издателя Microsoft.
• Имя папки издатель — это название компании, опубликовавшей программное обеспечение. Например, Microsoft.
• Имя папки приложение — это имя приложения или средства. Например, VSCode.
• Папка версия — это версия программного средства или приложения. Например, 1.0.0.

Значения PackageIdentifier и PackageVersion в манифесте должны соответствовать издателю, а также именам и версии приложений в пути к папке манифеста. Дополнительные сведения см. в статье Создание манифеста пакета.

Таким образом, чтобы настроить режим разреженной загрузки для всех манифестов издателя, необходимо ввести следующую команду:

• Если вы используете Git версии 2.37.0 или более поздней, выполните следующую команду, чтобы настроить разреженную проверку для папки.

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

• Если вы используете старую версию Git, ознакомьтесь с документацией по Git по настройке разреженного извлечения для локального репозитория.

Обратите внимание, что указанная выше команда переопределит все текущие параметры разреженного извлечения и настроит его только для одной папки. Для настройки разреженного извлечения в нескольких папках, см. документацию Git.

Шаг 5. Проверка репозитория

Теперь можно применить параметры разреженного извлечения, выполнив обычную команду извлечения.

git checkout

Даже если папка, которую вы хотите отправить, еще не была зафиксирована в репозитории, необходимо по-прежнему запустить команду извлечения, так как невозможно добавить (и таким образом зафиксировать) что-либо без внутренних элементов Git, которые он настраивает (индекс).

Если вы отправляете несколько заявок, создайте ветку вместо форка. Сейчас поддерживается отправка только одного файла манифеста за раз.

git checkout -b <branch-name>

Шаг 6. Добавление манифеста в локальный репозиторий

Добавьте файлы в следующую папку (формат объяснен в шаге 4): манифестов / букв / издателя / приложения / версии

Шаг 7. Отправка манифеста в удаленный репозиторий

Теперь вы можете отправить новый манифест в удаленный репозиторий.

1. Добавить файлы, зафиксировать изменения и предоставить сведения об отправке можно с помощью команды commit.

   git commit -m "Submitting ContosoApp version 1.0.0" --all
   

2. Чтобы отправить изменения в удаленный репозиторий, используйте команду push.

   git push
   

Шаг 8. Создание pull request

После того как отправите изменения, вернитесь на страницу https://github.com/microsoft/winget-pkgs и создайте запрос на слияние вашего форка или ветки с основной ветвой.

Процесс отправки

При создании запроса на pull request запускается автоматизированный процесс для проверки манифестов и проверки вашего запроса. Во время этого процесса мы проведем тесты средств установки и установленных двоичных файлов, чтобы проверить отправку.

Мы добавляем метки к запросу на вытягивание, чтобы вы могли отслеживать ход его выполнения. Дополнительные сведения о метках и процессе см. в разделе метки запроса на вытягивание ниже.

По завершении отправленные вами данные будут вручную проверены модератором. После утверждения приложение будет добавлено в каталог Диспетчер пакетов Windows.

Если в ходе процесса произойдет ошибка, мы вас уведомим, и наши метки и бот помогут вам исправить отправку. Список распространенных ошибок см. в разделе "Процесс проверки" ниже.

Процесс проверки

При создании запроса на pull request для отправки манифеста в репозиторий Диспетчера пакетов Windows запускается автоматизированный процесс, который проверяет манифест и обрабатывает запрос на pull request. Метки GitHub используются для обозначения хода выполнения и связи с нами.

Ожидания по отправке

Все отправки приложений в репозиторий Диспетчера пакетов Windows должны соответствовать политикам репозитория Диспетчера пакетов Windows.

Ожидания отправки:

• Манифест соответствует требованиям схемы.
• Все URL-адреса в манифесте ведут к надежным веб-сайтам.
• Установщик и приложение не содержат вирусов. По ошибке пакет может быть идентифицирован как вредоносная программа. Если вы считаете, что это ложное срабатывание, то можете отправить установщик для анализа команде Microsoft Defender.
• Корректно установить и удалить приложение могут как администраторы, так и другие пользователи.
• Установщик поддерживает неинтерактивные режимы.
• Все записи манифеста точны и не вводят в заблуждение.
• Установщик поставляется непосредственно с веб-сайта издателя.

Для получения полного списка политик см. Windows диспетчер пакетов policies.

Метки запроса на включение внесенных изменений

Во время проверки к pull requests применяется набор меток для передачи информации о прогрессе. Некоторые метки укажут вам на необходимость выполнить определенные действия, а другие будут направлены команде разработчиков Диспетчера пакетов Windows.

Метки состояния

В приведенной ниже таблице описаны возможные метки состояния.

Метка	Сведения
azure-Pipeline-Passed	Манифест завершил тестовый проход. Он ожидает утверждения. Если во время тестовой проверки не будут обнаружены проблемы, оно будет автоматически одобрено. Если тест не будет пройден, она может быть отмечена для ручной проверки.
блокирующая проблема	Данный ярлык указывает, что pull request нельзя утвердить, так как есть блокирующая ошибка. Часто можно определить, в чем заключается проблема блокировки, по указателю ошибки.
Нуждается во внимании	Метка означает, что pull request должна быть рассмотрена командой разработчиков Диспетчера пакетов Windows. Это может быть вызвано ошибкой при тестировании, которую необходимо проверить вручную, или комментарием, добавленным к запросу участниками сообщества.
Требуется отзыв автора	Произошел сбой отправки данных. Мы повторно передадим вам pull request. Если вы не устраните эту проблему в течение 10 дней, бот закроет этот запрос. Метки Needs-Author-Feedback обычно добавляются в случае сбоя pull request, который должен быть обновлен, или если у ревьюера есть вопросы.
Проверка завершена	Указывает на то, что тестирование успешно завершено и ваш pull request будет объединен.

Метки ошибок

В приведенной ниже таблице описаны возможные метки ошибок. Не все случаи ошибок будут назначены вам немедленно. В некоторых случаях может возникнуть необходимость проверки вручную.

Метка	Сведения
binary-Validation-Error	Приложение, включенное в этот pull request, не прошло тест Сканирование установщиков. Этот тест предназначен для того, чтобы приложение устанавливалось во всех средах без предупреждений. Дополнительные сведения об этой ошибке см. в разделе об ошибке двоичной проверки ниже.
времени ожидания для анализа ошибок	Время выполнения теста Binary-Validation-Test истекло. Пулл-реквест будет назначен разработчику Диспетчера пакетов Windows для рассмотрения.
Ошибка-Хэш-Несоответствие	Не удалось обработать отправленный манифест из-за несоответствия хэша InstallerSha256, предоставленного для InstallerURL. Измените InstallerSha256 в pull request и попробуйте снова.
Ошибка-Установщик-Доступность	Службе проверки не удалось скачать установщик. Возможно, это связано с блокированием диапазонов IP-адресов Azure или неправильным URL-адресом установщика. Проверьте правильность InstallerURL и повторите попытку. Если вы считаете, что произошла ошибка, добавьте комментарий, и pull request будет назначен инженеру Диспетчера пакетов Windows для изучения.
manifest-Installer-Validation-Error	Несоответствия или отсутствующие значения присутствуют в манифесте во время оценки пакета MSIX.
Ошибка пути манифеста	Файлы манифеста должны быть размещены в определенной структуре папок. Эта метка указывает на проблему с путем отправляемых файлов. Например, структура папок не соответствует требуемому формату. Обновите манифест и путь, а затем повторно отправьте запрос.
Ошибка проверки манифеста	Отправленный манифест содержит синтаксическую ошибку. Устраните проблемы с синтаксисом манифеста и повторите отправку. См. дополнительные сведения о формате и схеме манифеста.
PullRequest-Error	Запрос на слияние недопустим, так как не все файлы, которые были отправлены, находятся в каталоге манифеста или в запросе содержится более одного пакета или версии. Обновите запрос, чтобы устранить эту ошибку, и повторите попытку.
URL-validation-Error	Тесту проверки URL-адресов не удалось найти URL-адрес, и он вернул код состояния ошибки HTTP (403 или 404), либо произошел сбой при проверке репутации URL-адреса. Вы можете определить, какой URL-адрес рассматривается, просмотрев сведения о проверке пулреквеста. Чтобы устранить эту проблему, измените URL-адреса, чтобы устранить код состояния ошибки HTTP. Если проблема не связана с кодом состояния ошибки HTTP, вы можете отправить URL-адрес для проверки, чтобы избежать снижения репутации.
validation-Defender-Error	Во время динамического тестирования Microsoft Defender была обнаружена проблема. Чтобы воспроизвести эту проблему, установите приложение, а затем запустите полное сканирование Microsoft Defender. Если вы можете воспроизвести проблему, исправьте двоичный файл или отправьте его для анализа, чтобы получить помощь в случае ложноположительного результата. Если проблему воспроизвести не удается, добавьте комментарий, чтобы разработчики Диспетчера пакетов Windows изучили этот вопрос.
проверки домена	Тест определил домен, если InstallerURL не соответствует ожидаемому домену. Согласно политикам Диспетчера пакетов Windows InstallerUrl должен поступать непосредственно с места выпуска независимого производителя ПО. Если вы считаете, что это ложное срабатывание, добавьте комментарий к пулл-реквесту, чтобы инженеры Диспетчера пакетов Windows обсудили этот вопрос.
Ошибка валидации	Во время ручного утверждения проверка Диспетчера пакетов Windows не прошла. Для выполнения дальнейших действий ознакомьтесь с сопроводительным комментарием.
validate-Executable-Error	Во время тестирования установки не удалось обнаружить основное приложение. Убедитесь, что приложение правильно устанавливается на всех платформах. Если ваше приложение не устанавливает другое приложение, но его все равно нужно включить в репозиторий, добавьте комментарий к pull request, чтобы инженеры Диспетчера пакетов Windows могли рассмотреть проблему.
Проверка-хеша-подтверждение-не выполнено	Во время тестирования установки не удалось установить приложение, так как InstallerSha256 больше не соответствует хэшу InstallerURL. Это может произойти, если приложение находится за пользовательским URL-адресом, а установщик был обновлен без обновления InstallerSha256. Чтобы устранить эту ошибку, обновите InstallerSha256, связанный с InstallerURL, и повторите отправку.
validate-HTTP-Error	URL-адрес, используемый для установщика, не использует протокол HTTPS. Обновите InstallerURL, чтобы использовать HTTPS, и повторно отправьте пулл-реквест.
проверки непрямого URL-адреса	URL-адрес не поступает непосредственно от сервера независимого поставщика программного обеспечения. Тестирование определило, что используется перенаправитель. Это не разрешено, поскольку политики Диспетчера пакетов Windows требуют, чтобы InstallerUrl поступал непосредственно из места выпуска независимого поставщика программного обеспечения. Удалите перенаправление и повторите отправку.
Ошибка-Проверка-Установка	Во время проверки этого пакета вручную произошла общая ошибка. Для выполнения дальнейших действий ознакомьтесь с сопроводительным комментарием.
проверка-конфликт-слияния	Невозможно выполнить проверку этого пакета из-за конфликта при слиянии. Устраните конфликт слияния и отправьте пулл-реквест повторно.
Валидация-MSIX-Зависимость	Пакет MSIX зависит от пакета, который не удалось разрешить. Обновите пакет, включив в него недостающие компоненты, или добавьте зависимость в файл манифеста и повторно отправьте pull request.
проверка неутвержденного URL	Тест определил домен, если InstallerURL не соответствует ожидаемому домену. Согласно политикам Диспетчера пакетов Windows InstallerUrl должен поступать непосредственно с места выпуска независимого производителя ПО.
Проверка-без вмешательства-не удалась	Во время установки истекло время ожидания теста. Скорее всего, это связано с тем, что приложение не устанавливается без участия пользователя. Это также может быть вызвано некоторыми другими ошибками и остановкой теста. Убедитесь, что вы можете установить манифест без действий со стороны пользователя. Если вам нужна помощь, добавьте комментарий в pull request, и инженеры Windows диспетчер пакетов изучат этот вопрос.
validate-Uninstall-Error	Во время тестирования удаления выяснилось, что приложение не выполнило полную очистку после удаления. Более подробная информация приведена в сопроводительном комментарии.
Проверка-зависимость VCRuntime	Пакет зависит от среды выполнения C++, которую не удалось разрешить. Обновите пакет, включив в него недостающие компоненты, или добавьте зависимость в файл манифеста и повторно отправьте pull request.

Метки политик в отношении содержимого

В приведенной ниже таблице перечислены метки политик в отношении содержимого. Если добавляется одна из этих меток, то в метаданных манифеста запускается дополнительная проверка содержимого вручную, чтобы обеспечить соответствие метаданных политикам Диспетчера пакетов Windows.

Метка	Сведения
Policy-Test-2.1	См. раздел Общие требования к содержимому.
Policy-Test-2.2	См. раздел Содержимое, включая названия и логотипы (оригинальные и третьих лиц).
Policy-Test-2.3	См. раздел Риск ущерба.
Policy-Test-2.4	См. раздел Содержимое дискредитирующего, клеветнического, порочащего или угрожающего характера.
policy-test-2.5	См. раздел Оскорбительное содержимое.
Policy-Test-2.6	См. раздел Алкоголь, табак, оружие и наркотики.
policy-test-2.7	См. раздел Содержимое для взрослых.
policy-test-2.8	См. раздел Противозаконная деятельность.
policy-test-2.9	См. раздел Чрезмерное употребление ненормативной лексики и неприемлемое содержимое.
Policy-Test-2.10	См. раздел Специальные требования для страны или региона.
policy-test-2.11	См. раздел Возрастные категории.
тест политики-2.12	См. Созданное пользователем содержимое.

Внутренние метки

В таблице ниже перечислены метки внутренних ошибок. При обнаружении внутренних ошибок pull request будет передан инженерам Диспетчера пакетов Windows для расследования.

Метка	Сведения
Домен внутренней ошибки	Произошла ошибка при проверке домена URL-адреса.
внутренняя-ошибка-Динамическое-Сканирование	Произошла ошибка во время проверки установленных двоичных файлов.
Политика внутренней ошибки - ключевое слово	Произошла ошибка при проверке манифеста.
внутренняя ошибка-манифеста	Произошла ошибка при проверке манифеста.
Внутренняя ошибка — noArchitectures	Произошла ошибка, так как тест не мог определить архитектуру приложения.
Внутренняя ошибка - Нет поддерживаемых архитектур	Произошла ошибка, так как текущая архитектура не поддерживается.
внутренняя ошибка-PR	Во время обработки пул-реквеста произошла ошибка.
Внутренний-Ошибка-Статический-Скан	Во время статического анализа установщиков произошла ошибка.
Внутренняя ошибка URL	Произошла ошибка при проверке репутации установщиков.
Внутренняя ошибка	Во время тестового прохода произошел общий сбой или неизвестная ошибка.

Ошибка двоичной проверки

Если проверка вашего запроса на вытягивание завершается сбоем теста Installers Scan и получает метку Binary-Validation-Error, это означает, что приложение не удалось установить во всех средах.

Тест сканирования установщиков

Чтобы обеспечить оптимальное взаимодействие с пользователем при установке приложений, Диспетчер пакетов Windows должен гарантировать нормальную установку всех приложений на компьютерах с любой версией среды. Один из ключевых тестов заключается в том, чтобы обеспечить установку всех приложений без предупреждений на различных популярных конфигурациях антивирусных программ. В Windows предоставляется встроенная антивирусная программа Microsoft Defender, но многие корпоративные клиенты и пользователи используют другие антивирусные программы.

Каждая отправка в репозиторий Диспетчера пакетов Windows проверяется несколькими антивирусными программами. Все эти программы используют разные алгоритмы для обнаружения вирусов, потенциально нежелательных приложений и вредоносных программ.

Устранение ошибок при проверке двоичных файлов

Если приложение не проходит такую проверку, корпорация Майкрософт сначала обращается к производителю антивирусной программы, чтобы проверить возможность ложноположительного результата. Во многих случаях производители антивирусных программ вносят коррективы в свои алгоритмы, после чего приложение успешно проходит проверку.

Иногда поставщик антивирусной программы не может определить, является ли обнаруженная аномалия кода ложноположительной. В этом случае приложение нельзя добавить в репозиторий Диспетчера пакетов Windows. Запрос на pull request отклоняется с меткой Binary-Validation-Error.

Если к вашему пул-реквесту применена метка Binary-Validation-Error, обновите программное обеспечение, удалив код, обнаруженный как потенциально нежелательное приложение.

Иногда подлинные инструменты, используемые для отладки и низкоуровневых операций, выглядят как потенциально нежелательные приложения для антивирусных программ. Это связано с тем, что необходимый для отладки код имеет похожую сигнатуру, как у вредоносных программ. Хотя такие подходы к написанию кода законны, к сожалению, публикация таких приложений в репозитории Диспетчера пакетов Windows запрещена.

Устранение неполадок при отправке

Если отправка Диспетчера пакетов для Windows завершается ошибкой, можно использовать метки, описанные выше, чтобы изучить причину сбоя.

Чтобы проанализировать сбои запросов на слияние, выполните следующие действия:

1. Ошибка запроса на внесение изменений отображается внизу веб-страницы со строкой Некоторые проверки не пройдены. Щелкните ссылку Details (Подробнее) рядом с непройденной проверкой, чтобы перейти на страницу Azure Pipelines.

   

2. На странице Azure Pipelines щелкните ссылку 0 errors / 0 warnings (Ошибок: 0, предупреждений: 0).

   

3. На следующей странице выберите неудавшуюся задачу.

   

4. На следующей странице будут показаны результаты сбоя задания. Эти выходные данные помогут вам определить, какие изменения вы должны внести для исправления манифеста.

   В приведенном ниже примере сбой произошел при выполнении задачи Installation Validation (Проверка установки).