Add retries to publish steps #7892
Conversation
|
I chose 10 because the time between retries would then have summed to over 2 minutes. https://learn.microsoft.com/en-us/azure/devops/pipelines/process/tasks?view=azure-devops&tabs=yaml#number-of-retries-if-task-failed |
There was a problem hiding this comment.
PR Overview
This PR adds a retry mechanism to address file locking issues encountered during artifact and log publishing in the pipeline.
- Introduces a new parameter (retryCountOnTaskFailure: 10) in the artifact publishing step.
- Adds the same retry mechanism to the logs publishing step, in both the common and official job templates.
Reviewed Changes
| File | Description |
|---|---|
| eng/common/templates/job/job.yml | Adds retryCountOnTaskFailure for both artifact and log publishing steps |
| eng/common/templates-official/job/job.yml | Adds retryCountOnTaskFailure for artifact and log publishing steps |
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
Comments suppressed due to low confidence (4)
eng/common/templates/job/job.yml:49
- [nitpick] Consider adding tests to verify that the new retry mechanism resolves file locking issues during artifact publishing.
retryCountOnTaskFailure: 10 # for any logs being locked
eng/common/templates/job/job.yml:60
- [nitpick] Consider adding tests to verify that the new retry mechanism resolves file locking issues during log publishing.
retryCountOnTaskFailure: 10 # for any logs being locked
eng/common/templates-official/job/job.yml:33
- [nitpick] Consider adding tests to verify that the new retry mechanism resolves file locking issues during artifact publishing in the official template.
retryCountOnTaskFailure: 10 # for any logs being locked
eng/common/templates-official/job/job.yml:42
- [nitpick] Consider adding tests to validate that the retry mechanism properly handles file locking during log publishing in the official template.
retryCountOnTaskFailure: 10 # for any logs being locked
| @@ -30,6 +30,7 @@ jobs: | |||
| PathtoPublish: '$(Build.ArtifactStagingDirectory)/artifacts' | |||
| ArtifactName: ${{ coalesce(parameters.artifacts.publish.artifacts.name , 'Artifacts_$(Agent.Os)_$(_BuildConfig)') }} | |||
| condition: always() | |||
| retryCountOnTaskFailure: 10 # for any logs being locked | |||
There was a problem hiding this comment.
Changes to eng/common will get overwritten by the next update from dotnet/arcade - looks like that happens once per month in Aspire. Any idea why publishing is failing so frequently here?
| @@ -30,6 +30,7 @@ jobs: | |||
| PathtoPublish: '$(Build.ArtifactStagingDirectory)/artifacts' | |||
| ArtifactName: ${{ coalesce(parameters.artifacts.publish.artifacts.name , 'Artifacts_$(Agent.Os)_$(_BuildConfig)') }} | |||
| condition: always() | |||
| retryCountOnTaskFailure: 10 # for any logs being locked | |||
There was a problem hiding this comment.
Changes to eng/common will get overwritten by the next update from dotnet/arcade - looks like that happens once per month in Aspire. Any idea why publishing is failing so frequently here?
There was a problem hiding this comment.
We can instead add a step to explicitly wait for dcp/dcpctrl processes to end.
github-actions
bot
added
the
area-codeflow
attempt to work around DCP log locking causing
System.IO.IOException: The process cannot access the file 'D:\a_work\1\a\artifacts\log\dcp\dcpctrl-1741041174-9644.log' because it is being used by another process.