|
| 1 | +--- |
| 2 | +author: gloridelmorales |
| 3 | +ms.author: glmorale |
| 4 | +ms.technology: devops-release-notes |
| 5 | +ms.date: 11/16/2021 |
| 6 | +ms.topic: include |
| 7 | +--- |
| 8 | + |
| 9 | +### Automatic retries for a task |
| 10 | + |
| 11 | +When you have a flaky task that fails intermittently in a pipeline, you may have to re-run the pipeline to have it succeed. In most cases, the best way to address a flaky task or script is by fixing the task or script itself. For instance, if your test task fails in a pipeline because of flaky tests, it is always a good idea to fix the flaky tests and make them more reliable. Similarly, if your script fails once in a while, it is better to fix the script, for instance by introducing retries within the script. |
| 12 | + |
| 13 | +However, there are some cases, where you might want to retry the task. A common use case for this is a task that downloads a package (e.g., Nuget, npm, etc). We have often observed that these tasks are susceptible to networking failures and to the transient failures on the package hosting servers. We heard your feedback that it would be better to automatically retry such failing tasks without having to restart the entire pipeline again. |
| 14 | + |
| 15 | +Based on your feedback, we've added a feature to automatically retry a task in a pipeline when it fails. If you use YAML pipelines, then you can set this input as follows: |
| 16 | + |
| 17 | +``` |
| 18 | +- task: <name of task> |
| 19 | + retryCountOnTaskFailure: <max number of retries> |
| 20 | + ... |
| 21 | +``` |
| 22 | + |
| 23 | +When using classic build or release pipelines, you can set this property under the control options for the task. |
| 24 | + |
| 25 | +Here are a few things to note when using retries: |
| 26 | + |
| 27 | +* The failing task is retried immediately. |
| 28 | +* There is no assumption about the idempotency of the task. If the task has side-effects (for instance, if it created an external resource partially), then it may fail the second time it is run. |
| 29 | +* There is no information about the retry count made available to the task. |
| 30 | +* A warning is added to the task logs indicating that it has failed before it is retried. |
| 31 | +* All of the attempts to retry a task are shown in the UI as part of the same task node. |
| 32 | + |
| 33 | +### Consume inputs from another task in a decorator |
| 34 | + |
| 35 | +We recently added a [feature](https://docs.microsoft.com/azure/devops/extend/develop/add-pipeline-decorator?view=azure-devops#specifying-a-target-task) to inject a task automatically into a pipeline before another target task in that pipeline. We are now enhancing that feature by letting you customize that injected task using the input parameters of the target task. The syntax for writing a decorator to do this is as follows: |
| 36 | + |
| 37 | +``` |
| 38 | +{ |
| 39 | + "contributions": [ |
| 40 | + { |
| 41 | + "id": <my-required-task>, |
| 42 | + "type": "ms.azure-pipelines.pipeline-decorator", |
| 43 | + "targets": [ |
| 44 | + "ms.azure-pipelines-agent-job.pre-task-tasks", |
| 45 | + "ms.azure-pipelines-agent-job.post-task-tasks" |
| 46 | + ], |
| 47 | + "properties": { |
| 48 | + "template": "my-decorator.yml", |
| 49 | + "targettask": <target-task-id>, |
| 50 | + "targettaskinputs": ["<name of input>"] |
| 51 | + } |
| 52 | + } |
| 53 | + ], |
| 54 | + ... |
| 55 | +} |
| 56 | +``` |
| 57 | + |
| 58 | +This feature only works when you use `pre-task-tasks` or `post-task-tasks` as the target for injection and specify the `targettask` in the properties section of the contribution. You can then add an additional property called `targettaskinputs` and specify a list of input parameter names accepted by the target task. These inputs are now made available to the injected task. |
| 59 | + |
| 60 | +A common use case that can be accomplished by such a scenario is as follows. Let's say you want to inject a task that will automatically log the name of the artifact being published by a build. The name of the artifact is an input to the `PublishBuildArtifacts` task. Your injected task can now get the same input parameter and use it for logging. |
| 61 | + |
| 62 | +### Improvements to service connections usage history |
| 63 | + |
| 64 | +When a pipeline uses a [service connection](https://docs.microsoft.com/azure/devops/pipelines/library/service-endpoints?view=azure-devops&tabs=yaml), that usage is logged in the connection's history. Administrators of the service connection can review the usage history by navigating to project settings and selecting the appropriate service connection. There were some issues with the usage history of service connections that have been fixed with this update. Fixes include the following: |
| 65 | + |
| 66 | +* When a service connection is used in a [deployment job](https://docs.microsoft.com/azure/devops/pipelines/process/deployment-jobs?view=azure-devops) (instead of a regular job), that usage was not being logged. |
| 67 | +* If you used multiple service connections in multiple stages of a pipeline, all the service connections would show a record in their usage history even though some of the stages were skipped. |
| 68 | +### The default agent specification for Classic pipelines is now Windows-2019 |
| 69 | + |
| 70 | + |
| 71 | +In the last release notes, we [announced](https://docs.microsoft.com/azure/devops/release-notes/2021/sprint-194-update#announcing-a-deprecation-schedule-for-windows-2016-hosted-images) a deprecation schedule for `vs2017-win2016` hosted images. In preparation for that, we are now changing the default agent specification when creating new pipelines in Classic pipelines to `windows-2019`. |
| 72 | + |
| 73 | +> [!div class="mx-imgBorder"] |
| 74 | +>  |
0 commit comments