Dostępne kontrole stanu żądania ściągnięcia

usługi Azure DevOps

Testy stanu wymuszają standardy jakości, blokując scalanie, dopóki testy nie zostaną spełnione, czy nie zostaną spełnione skanowanie zabezpieczeń lub inne warunki. Azure DevOps Usługi i narzędzia zewnętrzne po sprawdzeniu stanu przy użyciu interfejsu API stanu żądania ściągnięcia.

Aby wymagać sprawdzenia stanu jako zasad gałęzi, utwórz zasady w sekcji Stan, aby sprawdzić i określić gatunek i nazwę sprawdzania w formacie genre/name. Żądanie ściągnięcia następnie blokuje scalanie do momentu sprawdzenia raportów succeeded.

Wartości stanu i zachowanie scalania

Gdy sprawdzanie stanu publikuje wynik w żądaniu ściągnięcia, zgłasza jedną z następujących wartości:

Value Zachowanie z wymaganymi zasadami Zachowanie przy użyciu opcjonalnych zasad
succeeded √ Odblokuje zasady Informacyjny
failed ✗ Bloki scalania Informacyjny
error ✗ Bloki scalania Informacyjny
pending ⏳ Blokuje scalanie (oczekiwanie na wynik) Informacyjny
notApplicable √ Pomija wymaganie zasad Informacyjny
notSet ⏳ Traktowane jako oczekujące Informacyjny

Uwaga / Notatka

Jeśli wymagane zasady są domyślnie ustawione na Zastosuj, można opublikować polecenie notApplicable , aby usunąć wymaganie zasad dla określonego żądania ściągnięcia bez zmiany konfiguracji zasad. Jest to przydatne, gdy sprawdzanie nie ma zastosowania do określonej zmiany.

Aby uzyskać ogólne instrukcje dotyczące dodawania zasad sprawdzania stanu, zobacz Konfigurowanie zasad gałęzi dla usługi zewnętrznej. Aby uzyskać zaawansowane opcje zasad, w tym autoryzowane ograniczenia tożsamości i ustawienia stosowania zasad, zobacz Dostosowywanie i rozszerzanie przepływów pracy żądań ściągnięcia ze stanem żądania ściągnięcia.

Sprawdzanie stanu Azure DevOps pierwszej firmy

Poniżej przedstawiono jedyne kontrole stanu opublikowane natywnie przez usługi Azure DevOps Services. Każde sprawdzenie używa stałej wartości gatunku , więc można skonfigurować zasady gałęzi przed lub po wpisaniu pierwszego stanu przez usługę. Wszystkie inne kontrole stanu pochodzą z usług zewnętrznych za pośrednictwem interfejsu API stanu żądania ściągnięcia.

GitHub Advanced Security dla usługi Azure DevOps

Te testy stanu wymagają włączenia GitHub Advanced Security dla Azure DevOps w repozytorium. Testy oceniają luki w zabezpieczeniach wykryte w ramach skanowania kodu (CodeQL), skanowania zależności i skanowania wpisów tajnych.

Gatunek Name Stan do sprawdzenia Description
AdvancedSecurity AllHighAndCritical AdvancedSecurity/AllHighAndCritical Bloki są scalane, gdy w repozytorium istnieje dowolna nierozwiązana luka w zabezpieczeniach o krytycznym lub wysokiej ważności (kod, zależność lub wpis tajny). Wymaga zasad weryfikacji kompilacji z włączonymi zadaniami potoku Advanced Security.
AdvancedSecurity NewHighAndCritical AdvancedSecurity/NewHighAndCritical Blokuje scalanie, gdy żądanie ściągnięcia wprowadza nowe luki w zabezpieczeniach o krytycznym lub wysokiej ważności z dowolnego typu skanowania. Istniejące luki w zabezpieczeniach repozytorium nie blokują scalania. Wymaga zasad weryfikacji kompilacji z zadaniami potoku Advanced Security w celu skanowania gałęzi żądania ściągnięcia.

Uwaga / Notatka

Oba AdvancedSecurity testy stanu wymagają zasad weryfikacji kompilacji i zadań skanowania zaawansowanego zabezpieczeń skonfigurowanych przy Wait for Processing: true użyciu w celu zapewnienia, że stany odzwierciedlają najnowsze wyniki skanowania. W przypadku skanowania zależności lub skanowania kodu (CodeQL) włącz Wait for Processing zadanie AdvancedSecurity-Publish . W przypadku skanowania kodu włącz je również w AdvancedSecurity-CodeQL-Analyze zadaniu. Oba testy są wyświetlane na liście rozwijanej Stan, aby sprawdzić po pierwszym pomyślnym uruchomieniu potoku przy użyciu skanowania zaawansowanego zabezpieczeń.

Wskazówka

Jeśli repozytorium ma istniejące nierozwiązane alerty, zacznij od AdvancedSecurity/NewHighAndCritical , aby uniknąć natychmiastowego blokowania wszystkich żądań ściągnięcia. Przeprowadź migrację do AdvancedSecurity/AllHighAndCritical po rozwiązaniu listy prac alertu.

Aby uzyskać instrukcje dotyczące konfiguracji, zobacz Konfigurowanie kontroli stanu żądania ściągnięcia.

Important

Pozostaw wartości domyślne opcji zaawansowanych podczas konfigurowania zasad sprawdzania stanu. Zmiana autoryzowanej tożsamości lub wymaganie identyfikatora iteracji uniemożliwia prawidłowe publikowanie sprawdzania stanu.

pokrycie kodu Azure Pipelines

Azure Pipelines automatycznie publikuje sprawdzanie stanu pokrycia kodu, gdy potok publikuje wyniki pokrycia kodu dla żądania ściągnięcia. Gatunek jest nazwą potoku, więc dokładna genre/name wartość zależy od sposobu nazwania potoku.

Gatunek Name Stan do sprawdzenia Description
{pipeline-name} codecoverage {pipeline-name}/codecoverage Raportuje wartość procentową pokrycia różnic dla wierszy zmienionych w żądaniu ściągnięcia. Porady domyślnie; nie blokuje scalania, chyba że skonfigurowano jako wymagane zasady gałęzi z minimalnym progiem pokrycia.

Domyślny próg przekazywania to 70% pokrycie różnic. Aby dostosować próg i inne ustawienia, dodaj azurepipelines-coverage.yml plik do katalogu głównego repozytorium:

coverage:
  status:
    comments: on
    diff:
      target: 80

Zastąp 80 element wartością procentową minimalnego pokrycia różnic.

Aby uzyskać instrukcje dotyczące konfiguracji, zobacz Wymuszanie ochrony gałęzi za pomocą zasad pokrycia kodu.

Wskazówka

Gatunek pochodzi z nazwy wyświetlanej potoku w Azure Pipelines; nie jest to oddzielnie konfigurowalna wartość. Na przykład potok o nazwie CI — main używa CI - Main/codecoverage jako stanu do sprawdzenia wartości. Kontrole stanu są wyświetlane tylko na liście rozwijanej po opublikowaniu co najmniej jednego stanu w żądaniu ściągnięcia. W przypadku nowych integracji, które nie zostały jeszcze uruchomione, wpisz genre/name wartość bezpośrednio w polu.

Niestandardowe i zewnętrzne kontrole stanu

Każda usługa korzystająca z interfejsu API stanu żądania ściągnięcia może opublikować sprawdzanie stanu żądań ściągnięcia. Aby opublikować sprawdzanie stanu za pośrednictwem interfejsu API REST, tożsamość wywołująca musi mieć uprawnienie Współtworzenie żądań ściągnięcia w repozytorium.

Gdy usługa opublikuje stan, zostanie genre/name wyświetlona na liście rozwijanej Stan, aby sprawdzić podczas dodawania zasad. W przypadku nowych usług, które nie zostały jeszcze opublikowane, wpisz genre/name wartość bezpośrednio.

Typowe wzorce integracji

Typ integracji Description Examples
Kompilowanie i testowanie serwerów Zewnętrzne narzędzia ciągłej integracji, które publikują wyniki powodzenia lub niepowodzenia po uruchomieniu testów względem gałęzi żądania ściągnięcia. Jenkins, GitLab CI, CircleCI, Travis CI
Analiza jakości kodu Narzędzia do analizy statycznej, które skanują kod pod kątem usterek, luk w zabezpieczeniach i zapachów kodu. SonarQube, SonarCloud
Skanery zabezpieczeń Skanery luk w zabezpieczeniach bez Microsoft, które publikują wyniki po skanowaniu zmian żądania ściągnięcia. Obsługuje również wyniki formatu SARIF. Snyk, Checkmarx, WhiteSource (), rozwiązania zabezpieczające firmy Microsoft DevOps
Zgodność i zasady Narzędzia wymuszania zasad, które weryfikują licencjonowanie, standardy kodu, wymagania prawne lub gotowość wdrożenia. Niestandardowe kontrolery zgodności, bramy wdrożenia, skanery licencji
GitHub Actions Sprawdzanie przepływów pracy GitHub Actions jest wyświetlane w Azure DevOps żądania ściągnięcia, gdy repozytorium jest połączone z GitHub. Aby uzyskać szczegółowe informacje o konfiguracji, zobacz Azure DevOps GitHub integracja. Dowolny przepływ pracy GitHub Actions może publikować stan
Zatwierdzenia i bramy Usługi wymagające ręcznego lub zautomatyzowanego zatwierdzania przed zezwoleniem na scalanie. ServiceNow, niestandardowe usługi zatwierdzania za pośrednictwem interfejsu API REST

Opcje konfiguracji zasad

Podczas dodawania zasad sprawdzania stanu można skonfigurować:

  • Wymaganie dotyczące zasad: ustaw zasady zgodnie z wymaganiami (bloki scalają, chyba że sprawdzanie przebiegnie) lub opcjonalne (tylko informacyjne).
  • Tożsamość autoryzowana: ogranicz, które konta mogą publikować wartości stanu spełniające zasady. Pozostaw pole puste, aby zezwolić na dowolne konto.
  • Warunki resetowania: określ, czy stan jest resetowany po wypchnięciu nowego zatwierdzenia. Domyślnie wypychanie nowego resetowania zatwierdzenia wymaga sprawdzenia stanu do oczekujących, co zmusza je do oceny najnowszego kodu. Aby zezwolić na utrwalanie stanu w zatwierdzeniach, wyłącz opcję Resetuj stan zawsze, gdy pojawią się nowe zmiany.
  • Możliwość stosowania zasad: wybierz, czy zasady są stosowane natychmiast (zastosuj domyślnie), czy tylko po opublikowaniu pierwszego stanu (warunkowe).
    • Zastosuj domyślnie: bloki zasad są scalane do momentu opublikowania succeeded stanu. Możesz opublikować wpis notApplicable , aby pominąć wymaganie dla określonego żądania ściągnięcia.
    • Warunkowe: zasady stają się aktywne tylko po wpisaniu pierwszego stanu sprawdzania.
  • Filtr ścieżki: ogranicz zasady do żądań ściągnięcia, które modyfikują pliki w określonych ścieżkach (opcjonalnie).

Aby zaimplementować niestandardowe sprawdzanie stanu, zobacz:

Treści powiązane

  • Last updated on