Przesyłanie manifestu do repozytorium

Po utworzeniu manifestu pakietu opisującego aplikację możesz przesłać manifest do repozytorium Menedżera pakietów systemu Windows. Jest to repozytorium dostępne publicznie, które zawiera kolekcję manifestów, do których może uzyskać dostęp narzędzie zestawu . Aby przesłać manifest, przekażesz go do repozytorium open source https://github.com/microsoft/winget-pkgs w usłudze GitHub.

Po przesłaniu żądania ściągnięcia w celu dodania nowego manifestu do repozytorium GitHub zautomatyzowany proces zweryfikuje plik manifestu i sprawdzi, czy pakiet jest zgodny z zasadami Menedżera pakietów systemu Windows i nie jest znany jako złośliwy. Jeśli ta walidacja zakończy się pomyślnie, pakiet zostanie dodany do publicznego repozytorium Menedżera pakietów systemu Windows, aby można go było odnaleźć za pomocą narzędzia klienckiego zestawu narzędzi. Zwróć uwagę na rozróżnienie między manifestami w repozytorium GitHub typu open source i publicznym repozytorium Menedżera pakietów systemu Windows.

Walidacja manifestu

Po przesłaniu manifestu https://github.com/microsoft/winget-pkgs do repozytorium w usłudze GitHub manifest zostanie automatycznie zweryfikowany i oceniony pod kątem bezpieczeństwa ekosystemu systemu Windows. Manifesty mogą być również przeglądane ręcznie.

Aby uzyskać więcej informacji na temat procesu weryfikacji, zobacz sekcję procesu weryfikacji poniżej.

Jak przesłać manifest

Aby przesłać manifest do repozytorium, wykonaj następujące kroki.

Krok 1. Weryfikowanie manifestu

Narzędzie zestawu udostępnia weryfikuje polecenie, aby potwierdzić, że manifest został utworzony poprawnie. Aby zweryfikować manifest, użyj tego polecenia.

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

Jeśli walidacja zakończy się niepowodzeniem, użyj błędów, aby zlokalizować numer wiersza i wprowadzić poprawkę. Po zweryfikowaniu manifestu możesz przesłać go do repozytorium.

Krok 2. Testowanie manifestu za pomocą piaskownicy systemu Windows

Repozytorium Menedżera pakietów systemu Windows zawiera skrypt, który zainstaluje Menedżera pakietów systemu Windows w piaskownicy na potrzeby testowania przesyłania manifestu. Aby uruchomić skrypt programu PowerShell, przejdź do repozytorium winget-pkgs. W programie PowerShell wprowadź następujące polecenie:

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

Może być konieczne zaktualizowanie tego skryptu przy użyciu właściwej ścieżki do pliku manifestu: .\Tools\SandboxTest.ps1 <path to manifest or manifest folder>

Zobacz pełny skrypt testowy piaskownicy w repozytorium winget-pkgs.

Krok 3. Klonowanie repozytorium

Aby utworzyć fork repozytorium Windows Package Manager Community i sklonować repozytorium na lokalną maszynę:

1. Przejdź do https://github.com/microsoft/winget-pkgs w przeglądarce i wybierz pozycję Fork.

2. W wierszu polecenia systemu Windows lub programie PowerShell użyj następującego polecenia, aby sklonować rozwidlenie.

   git clone <your-fork-name>
   

3. Jeśli wprowadzasz wiele zgłoszeń, utwórz gałąź zamiast forka. Obecnie zezwalamy tylko na jeden plik manifestu na przesłanie.

   git checkout -b <branch-name>
   

Krok 4. Dodawanie manifestu do repozytorium lokalnego

Pliki manifestu należy dodać do repozytorium w następującej strukturze folderów:

manifesty / list / wydawcy / aplikacji / w wersji

• manifesty folder jest folderem głównym dla wszystkich manifestów w repozytorium.
• Litera folderu jest pierwszą literą nazwy wydawcy małą literą. Na przykład m wydawcy Microsoft.
• Folder wydawcy jest nazwą firmy publikującej oprogramowanie. Na przykład firma Microsoft.
• Folder aplikacji to nazwa aplikacji lub narzędzia. Na przykład VSCode.
• Folder wersji jest wersją aplikacji lub narzędzia. Na przykład 1.0.0.

Wartości PackageIdentifier i PackageVersion w manifeście muszą być zgodne z wydawcą, nazwami aplikacji i wersją w ścieżce folderu manifestu. Aby uzyskać więcej informacji, zobacz Tworzenie manifestu pakietu.

Krok 5. Przesyłanie manifestu do repozytorium zdalnego

Teraz możesz przesłać nowy manifest do zdalnego repozytorium.

1. commit Użyj polecenia , aby dodać pliki i zatwierdzić zmianę i podać informacje dotyczące przesyłania.

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

2. Użyj polecenia , push aby wypchnąć zmiany do repozytorium zdalnego.

   git push
   

Krok 6: Utwórz wniosek o połączenie

Po zatwierdzeniu zmian wróć do https://github.com/microsoft/winget-pkgs i utwórz prośbę o połączenie, aby scalić swój fork lub gałąź z gałęzią główną.

Proces przesyłania

Gdy tworzysz pull request, rozpocznie się zautomatyzowany proces, który sprawdza manifesty i weryfikuje twój pull request. Podczas tego procesu uruchomimy testy instalatora oraz zainstalowanych binariów, aby zweryfikować zgłoszenie.

Dodajemy etykiety do prośby o ściągnięcie , aby można było śledzić jej postęp. Aby uzyskać więcej informacji na temat etykiet i procesu, zobacz sekcję etykiet żądania ściągnięcia poniżej.

Po zakończeniu przesyłanie zostanie ręcznie przejrzyone przez moderatora, a po jego zatwierdzeniu aplikacja zostanie dodana do katalogu Menedżera pakietów systemu Windows.

Jeśli podczas tego procesu wystąpi błąd, otrzymasz powiadomienie, a nasze etykiety i bot pomogą Ci w naprawieniu przesyłki. Aby uzyskać listę typowych błędów, zobacz sekcję procesów weryfikacji poniżej.

Proces weryfikacji

Gdy utworzysz żądanie zmian w celu przesłania manifestu do repozytorium Menadżera Pakietów Windows, rozpocznie to proces automatyczny, który weryfikuje manifest i przetwarza żądanie zmian. Etykiety usługi GitHub są używane do udostępniania postępu i umożliwiają komunikowanie się z nami.

Oczekiwania dotyczące przesyłania

Wszystkie przesłania aplikacji do repozytorium Menedżera pakietów systemu Windows powinny być zgodne z zasadami repozytorium Menedżera pakietów systemu Windows.

Oczekiwania dotyczące przesłanych wniosków:

• Manifest spełnia wymagania dotyczące schematu.
• Wszystkie adresy URL w manifeście prowadzą do bezpiecznych witryn internetowych.
• Instalator i aplikacja są wolne od wirusów. Pakiet może zostać zidentyfikowany jako złośliwe oprogramowanie przez pomyłkę. Jeśli uważasz, że jest to wynik fałszywie dodatni, możesz przesłać instalator do zespołu usługi Microsoft Defender w celu analizy.
• Aplikacja instaluje i odinstalowuje poprawnie zarówno dla administratorów, jak i nieadministratorów.
• Instalator obsługuje tryby nieinterakcyjne.
• Wszystkie wpisy manifestu są dokładne i nie mylące.
• Instalator pochodzi bezpośrednio z witryny internetowej wydawcy.

Aby uzyskać pełną listę zasad, zobacz Zasady Menedżera pakietów systemu Windows.

Etykiety żądań ściągnięcia

Podczas walidacji do komunikowania postępu stosuje się serie etykiet do żądań ściągnięcia. Niektóre etykiety przekierowują Cię do podjęcia działań, a inne zostaną skierowane do zespołu inżynierów menedżera pakietów systemu Windows.

Etykiety stanu

W poniższej tabeli opisano etykiety stanu , które mogą wystąpić.

Etykiety błędów

W poniższej tabeli opisano etykiety błędów , które mogą wystąpić. Nie wszystkie przypadki błędów zostaną przypisane tobie od razu. Niektóre mogą wyzwalać ręczną walidację.

Etykiety zasad zawartości

W poniższej tabeli wymieniono etykiety zasad polityki zawartości . Jeśli zostanie dodana jedna z tych etykiet, w metadanych manifestu wyzwolono dodatkową ręczną recenzję zawartości, aby upewnić się, że metadane są wykonywane zgodnie z zasadami menedżera pakietów systemu Windows .

Etykiety wewnętrzne

W poniższej tabeli wymieniono wewnętrzne etykiety błędów. W przypadku napotkania błędów wewnętrznych żądanie ściągnięcia zostanie przypisane do inżynierów Menedżera pakietów systemu Windows w celu zbadania.

Błąd weryfikacji binarnej

Jeśli walidacja pull requestu nie powiedzie się w teście Instalatorów i otrzyma etykietę Błąd-Walidacji-Binarnej, oznacza to, że aplikacja nie zainstalowała się we wszystkich środowiskach.

Test skanowania instalatorów

Aby zapewnić doskonałe środowisko użytkownika instalacji aplikacji, Menedżer pakietów systemu Windows musi upewnić się, że wszystkie aplikacje są instalowane na komputerach bez błędów, niezależnie od środowiska. Jednym z kluczowych testów jest upewnienie się, że wszystkie aplikacje są instalowane bez ostrzeżeń w różnych popularnych konfiguracjach oprogramowania antywirusowego. System Windows udostępnia wbudowany program antywirusowy Microsoft Defender, ale wielu klientów korporacyjnych i użytkowników korzysta z innego oprogramowania antywirusowego.

Każde przesłanie do repozytorium Menedżera pakietów systemu Windows odbywa się za pośrednictwem kilku programów antywirusowych. Wszystkie te programy mają różne algorytmy wykrywania wirusów służące do identyfikowania potencjalnie niechcianych aplikacji (PUA) i złośliwego oprogramowania.

Rozwiązywanie problemów z błędami weryfikacji binarnej

Jeśli weryfikacja aplikacji zakończy się niepowodzeniem, firma Microsoft najpierw spróbuje zweryfikować u dostawcy oprogramowania antywirusowego, czy oflagowane oprogramowanie jest fałszywie dodatnie. W wielu przypadkach po powiadomieniu i weryfikacji dostawca oprogramowania antywirusowego aktualizuje algorytm, a aplikacja przechodzi.

W niektórych przypadkach dostawca oprogramowania antywirusowego nie może określić, czy wykryta anomalia kodu jest fałszywie dodatnia. W takim przypadku nie można dodać aplikacji do repozytorium Menedżera pakietów systemu Windows. Żądanie ściągnięcia jest odrzucane z etykietą Binary-Validation-Error.

Jeśli w pull request otrzymasz etykietę Binary-Validation-Error, zaktualizuj oprogramowanie, aby usunąć kod wykryty jako PUA.

Czasami autentyczne narzędzia używane do debugowania i działań niskopoziomowych są wyświetlane jako PUA przez oprogramowanie antywirusowe. Dzieje się tak, ponieważ wymagany kod debugowania ma podobny podpis do niechcianego oprogramowania. Mimo że ta praktyka kodowania jest legalna, repozytorium Menedżera pakietów systemu Windows niestety nie może zezwalać na te aplikacje.

Rozwiązywanie problemów z przesyłaniem

Jeśli przesyłanie menedżera pakietów systemu Windows zakończy się niepowodzeniem, możesz użyć etykiet opisanych powyżej, aby zbadać przyczynę niepowodzenia.

Aby zbadać błędy żądań ściągnięcia, wykonaj następujące czynności:

1. Błąd pull request pojawia się na dole strony z ciągiem Niektóre sprawdzania nie powiodły się. Wybierz link Szczegóły obok nieudanej weryfikacji, aby przejść na stronę Azure Pipelines.

   

2. Na stronie Azure Pipelines wybierz łącze 0 błędów / 0 ostrzeżeń.

   

3. Na następnej stronie wybierz zadanie, które zakończyło się niepowodzeniem.

   

4. Na następnej stronie przedstawiono dane wyjściowe zadania, które zakończyło się niepowodzeniem. Dane wyjściowe powinny ułatwić zidentyfikowanie zmiany wymaganej do naprawienia manifestu.

   W poniższym przykładzie błąd wystąpił podczas zadania walidacji instalacji .