Ulepszenia kopiowania pulpitu nawigacyjnego
Z przyjemnością ogłaszamy pewne długo oczekiwane ulepszenia wersji zapoznawczej kopiowania pulpitu nawigacyjnego. Teraz możesz skopiować pulpit nawigacyjny do innego zespołu, tego samego zespołu lub innego projektu — a konfiguracja zespołu i zapytań zostanie zaktualizowana na nowym pulpicie nawigacyjnym. Dodatkowo minimalizuje to pracę wymaganą do tworzenia podobnych pulpitów nawigacyjnych od podstaw dla wielu zespołów.
Aby uzyskać szczegółowe informacje, zapoznaj się z następującymi opisami funkcji.
Ogólne
Azure Pipelines
- Automatyczne ponawianie prób dla zadania
- Używanie danych wejściowych z innego zadania w dekoratorze
- Ulepszenia historii użycia połączeń usług
- Domyślna specyfikacja agenta dla potoków klasycznych to teraz Windows-2019
Raportowanie
Ogólne
Przypisywanie roli administratora usługi Azure DevOps do grupy Azure AD
Rola administratora usługi Azure DevOps niezbędna do skonfigurowania zasad dzierżawy Azure AD w usłudze Azure DevOps można teraz przypisać do grup Azure AD. Dowiedz się więcej na temat używania grup Azure AD do zarządzania przypisaniami ról w Azure AD.
Azure Pipelines
Automatyczne ponawianie prób dla zadania
Jeśli w potoku występuje niestabilne zadanie, które nie powiedzie się sporadycznie, może być konieczne ponowne uruchomienie potoku, aby zakończyło się powodzeniem. W większości przypadków najlepszym sposobem rozwiązania problemu z zadaniu lub skryptem jest naprawienie samego zadania lub skryptu. Jeśli na przykład zadanie testowe zakończy się niepowodzeniem w potoku z powodu niesłychanych testów, zawsze dobrym pomysłem jest naprawienie flaky testów i zwiększenie ich niezawodności. Podobnie jeśli skrypt nie powiedzie się raz na chwilę, lepiej jest naprawić skrypt, na przykład wprowadzając ponawianie prób w skrycie.
Istnieją jednak pewne przypadki, w których warto ponowić próbę wykonania zadania. Typowym przypadkiem użycia jest zadanie, które pobiera pakiet (np. NuGet, npm itp.). Często zaobserwowaliśmy, że te zadania są podatne na błędy sieci i przejściowe błędy na serwerach hostujących pakiety. Słyszeliśmy twoją opinię, że lepiej byłoby automatycznie ponowić próbę wykonania takich zadań zakończonych niepowodzeniem bez konieczności ponownego ponownego uruchamiania całego potoku.
Na podstawie opinii dodaliśmy funkcję, aby automatycznie ponowić próbę wykonania zadania w potoku po awarii. Jeśli używasz potoków YAML, możesz ustawić te dane wejściowe w następujący sposób:
- task: <name of task>
retryCountOnTaskFailure: <max number of retries>
...
W przypadku korzystania z klasycznych potoków kompilacji lub wydania można ustawić tę właściwość pod opcjami sterowania dla zadania.
Poniżej przedstawiono kilka kwestii, które należy wziąć pod uwagę podczas używania ponownych prób:
- Zadanie zakończone niepowodzeniem jest natychmiast ponawiane.
- Nie ma założenia dotyczącego idempotencji zadania. Jeśli zadanie ma skutki uboczne (na przykład jeśli utworzono zasób zewnętrzny częściowo), może zakończyć się niepowodzeniem po drugim uruchomieniu.
- Nie ma informacji o liczbie ponownych prób udostępnionych zadaniu.
- Ostrzeżenie jest dodawane do dzienników zadań wskazujących, że nie powiodło się, zanim zostanie ponowione.
- Wszystkie próby ponawiania próby wykonania zadania są wyświetlane w interfejsie użytkownika w ramach tego samego węzła zadania.
Uwaga
Wymaga agenta w wersji 2.194.0 lub nowszej. Nieobsługiwane w przypadku zadań bez agenta.
Używanie danych wejściowych z innego zadania w dekoratorze
Niedawno dodaliśmy funkcję do automatycznego wstrzykiwania zadania do potoku przed innym zadaniem docelowym w tym potoku. Teraz ulepszamy tę funkcję, umożliwiając dostosowanie tego zadania wprowadzonego przy użyciu parametrów wejściowych zadania docelowego. Składnia pisania dekoratora do wykonania jest następująca:
{
"contributions": [
{
"id": <my-required-task>,
"type": "ms.azure-pipelines.pipeline-decorator",
"targets": [
"ms.azure-pipelines-agent-job.pre-task-tasks",
"ms.azure-pipelines-agent-job.post-task-tasks"
],
"properties": {
"template": "my-decorator.yml",
"targettask": <target-task-id>,
"targettaskinputs": ["<name of input>"]
}
}
],
...
}
Ta funkcja działa tylko w przypadku użycia pre-task-tasks lub post-task-tasks jako celu wstrzyknięcia i określenia targettask właściwości w sekcji właściwości udziału. Następnie można dodać dodatkową właściwość o nazwie targettaskinputs i określić listę nazw parametrów wejściowych akceptowanych przez zadanie docelowe. Te dane wejściowe są teraz dostępne dla wstrzykniętego zadania.
Typowy przypadek użycia, który można wykonać w takim scenariuszu, jest następujący. Załóżmy, że chcesz wstrzyknąć zadanie, które automatycznie zarejestruje nazwę artefaktu opublikowanego przez kompilację. Nazwa artefaktu to dane wejściowe PublishBuildArtifacts zadania. Wstrzyknięte zadanie może teraz uzyskać ten sam parametr wejściowy i użyć go do rejestrowania.
Ulepszenia historii użycia połączeń usług
Gdy potok używa połączenia z usługą, to użycie jest rejestrowane w historii połączenia. Administratorzy połączenia z usługą mogą przeglądać historię użycia, przechodząc do ustawień projektu i wybierając odpowiednie połączenie z usługą. Wystąpiły pewne problemy z historią użycia połączeń usług, które zostały rozwiązane w tej aktualizacji. Poprawki obejmują następujące elementy:
- Gdy połączenie z usługą jest używane w zadaniu wdrażania (zamiast zwykłego zadania), to użycie nie było rejestrowane.
- Jeśli użyto wielu połączeń usług w wielu etapach potoku, wszystkie połączenia usług będą pokazywać rekord w historii użycia, mimo że niektóre etapy zostały pominięte.
Domyślna specyfikacja agenta dla potoków klasycznych to teraz Windows-2019
W ostatnich informacjach o wersji ogłosiliśmy harmonogram vs2017-win2016 wycofania hostowanych obrazów. W ramach przygotowań do tego teraz zmieniamy domyślną specyfikację agenta podczas tworzenia nowych potoków w potokach klasycznych na windows-2019.
Raportowanie
Ulepszenia kopiowania pulpitu nawigacyjnego
Z przyjemnością ogłaszamy fazę 2 publicznej wersji zapoznawczej kopiowania pulpitu nawigacyjnego! Zapytania i konfiguracja są teraz przenoszone za pomocą operacji kopiowania. Dziękujemy za cierpliwość, ponieważ zajęło trochę więcej niż oczekiwano, aby wypracować niektóre problemy.
Wersja zapoznawcza jest domyślnie włączona z flagą funkcji Kopiuj środowisko pulpitu nawigacyjnego (w obszarze funkcje w wersji zapoznawczej).
Aby skopiować pulpit nawigacyjny, najpierw przejdź do pulpitu nawigacyjnego, który chcesz skopiować. Następnie kliknij menu, aby wyświetlić kopiuj pulpit nawigacyjny , a następnie kliknij go.
Następnie podaj nazwę i opis nowego pulpitu nawigacyjnego, a następnie wybierz typ pulpitu nawigacyjnego, Zespół lub Projekt. Podczas wybierania pulpitu nawigacyjnego zespołu nowy projekt i zespół są wybierane z odpowiednich pól rozwijanych. W przypadku pulpitu nawigacyjnego projektu wymagany jest tylko projekt.
Nastąpi przekierowanie do nowo utworzonego pulpitu nawigacyjnego po kliknięciu przycisku Utwórz . Widżety i układ pozostają takie same.
W tle folder o nazwie nowego pulpitu nawigacyjnego jest tworzony w zapytaniach udostępnionych. Wszystkie zapytania dotyczące nowego pulpitu nawigacyjnego są kopiowane do tego folderu. Nazwy zapytań pozostają takie same. Widżety z konfiguracją zespołu są aktualizowane wraz z nowym zespołem. Widżety z konfiguracją zespołu skopiowaną z pulpitu nawigacyjnego zespołu do pulpitu nawigacyjnego projektu zachowują oryginalną konfigurację.
Filtrowanie wartości null w widżecie wykresu spalonego
Teraz możesz filtrować wartość null przy użyciu kryteriów pola w widżecie wykresu spalonego. To zachowanie jest teraz spójne z zapytaniem przy użyciu tych samych kryteriów pola.
Następne kroki
Uwaga
Te funkcje zostaną wdrożone w ciągu najbliższych dwóch do trzech tygodni.
Przejdź do usługi Azure DevOps i przyjrzyj się.
Jak przekazać opinię
Chcielibyśmy usłyszeć, co myślisz o tych funkcjach. Użyj menu Pomocy, aby zgłosić problem lub podać sugestię.
Możesz również uzyskać porady i pytania, na które odpowiada społeczność w witrynie Stack Overflow.
Dzięki,
Aaron Hallberg