Azure Pipelines — aktualizacja Sprintu 195

Funkcje

Automatyczne ponawianie prób dla zadania

Jeśli w potoku występuje zadanie niestabilne lub zawodzące, które czasami kończy się niepowodzeniem, może być konieczne ponowne uruchomienie potoku, aby zakończyło się sukcesem. W większości przypadków najlepszym sposobem na rozwiązanie problemu z niestabilnym zadaniem lub skryptem jest naprawienie samego zadania lub skryptu. Na przykład, jeśli zadanie testowe kończy się niepowodzeniem w potoku z powodu niestabilnych testów, zawsze dobrym pomysłem jest naprawienie tych niestabilnych testów i podniesienie ich niezawodności. Podobnie, jeśli skrypt ulegnie awarii raz na jakiś czas, 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 polegające na pobraniu pakietu, na przykład NuGet, npm itp. Często zaobserwowaliśmy, że te zadania są podatne na błędy sieci i błędy przejściowe na serwerach hostujących pakiety. Słyszeliśmy Twoją opinię, że lepiej byłoby automatycznie ponowić próbę ponownego uruchomienia takich zadań zakończonych niepowodzeniem bez konieczności ponownego ponownego uruchamiania całego potoku.

Na podstawie opinii dodaliśmy funkcję umożliwiającą automatyczne ponawianie próby wykonania zadania w potoku w przypadku niepowodzenia. 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ść w obszarze opcji kontroli dla zadania.

Poniżej przedstawiono kilka kwestii, które należy zwrócić uwagę podczas używania ponownych prób:

  • Zadanie, które kończy się niepowodzeniem, jest natychmiast ponawiane.
  • Nie ma założenia dotyczącego idempotentności zadania. Jeśli zadanie ma skutki uboczne (na przykład jeśli utworzył zasób zewnętrzny częściowo), może zakończyć się niepowodzeniem po drugim uruchomieniu.
  • Brak informacji o liczbie ponownych prób dostępnych dla zadania.
  • 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 / Notatka

Wymaga agenta w wersji 2.194.0 lub nowszej. Nieobsługiwane w przypadku zadań bez agenta.

Korzystanie z danych wejściowych z innego zadania w dekoratorze

Niedawno dodaliśmy funkcję, która umożliwia automatyczne dodawanie 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 zapisu dekoratora w tym celu 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 wtedy, gdy używasz pre-task-tasks i post-task-tasks jako celów iniekcji oraz określasz wartość targettask w sekcji właściwości wkładu. 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 osiągnąć w takim scenariuszu, jest następujący. Załóżmy, że chcesz dodać zadanie, które automatycznie zarejestruje nazwę artefaktu publikowanego przez kompilację. Nazwa artefaktu jest danymi wejściowymi zadania PublishBuildArtifacts . Wprowadzone zadanie może teraz uzyskać ten sam parametr wejściowy i użyć go do rejestrowania.

Ulepszenia w historii użytkowania połączeń serwisowych

Gdy potok danych używa połączenia z usługą, to użycie jest rejestrowane w historii połączenia. Administratorzy połączenia usługi mogą przejrzeć 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), 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 obrazów przechowywanych. W ramach przygotowań do tego celu zmieniamy teraz domyślną specyfikację agenta podczas tworzenia nowych potoków w potokach klasycznych na windows-2019.

Specyfikacja agenta

Dalsze kroki

Uwaga / Notatka

Te funkcje będą wdrażane w ciągu najbliższych dwóch do trzech tygodni.

Przejdź do usługi Azure DevOps i przyjrzyj się.

Przejdź do usługi Azure DevOps

Jak przekazać opinię

Chcielibyśmy usłyszeć, co myślisz o tych funkcjach. Użyj menu Pomocy, aby zgłosić problem lub podać sugestię.

Utwórz sugestię

Możesz również uzyskać porady i odpowiedzi na pytania społeczności w witrynie Stack Overflow.

  • Ostatnia aktualizacja o