Support pipeline artifacts when using streaming publishing #15595
Conversation
Pipeline artifacts were not supported previously, due to differences in how the download URL needs to be determined and constructed. This was blocking at least a partial move of the VMR onto pipeline artifacts, and generally a move onto pipeline artifacts for .NET overall. To fix this, I've implemented support for both. The system will first use the artifact API to determine what the artifact type is, then construct a helper for future usage to obtain a download url given a file name. - Added tests for the new functionality and factored out some old tests into another class - Removed old container id calls and method.
| string uri = | ||
| $"{AzureDevOpsBaseUrl}/{AzureDevOpsOrg}/{AzureProject}/_apis/build/builds/{BuildId}/artifacts?api-version={AzureDevOpsFeedsApiVersion}"; | ||
| // Look up or create a helper for the specified artifact type. | ||
| if (!_artifactUrlHelpers.TryGetValue(artifactName, out IArtifactUrlHelper helper)) |
There was a problem hiding this comment.
Can GetOrAdd instead be used here?
There was a problem hiding this comment.
I played around with it and went with a different approach. Since the thing does make an http call, it's a waste to accidentally do it more than once due to threading. So I stuck a lock in there.
| bool setAutomaticDecompression, | ||
| string projectName = null, | ||
| string versionOverride = null) | ||
| private HttpClient CreateAzdoClient(string tokenOverride = null) |
There was a problem hiding this comment.
We no longer enforce a handler timeout?
There was a problem hiding this comment.
There was a problem hiding this comment.
huh - somehow I missed - my bad.
src/Microsoft.DotNet.Build.Tasks.Feed/src/PublishArtifactsInManifestBase.cs
Show resolved
Hide resolved
|
Latest promotion build with recent changes: https://dev.azure.com/dnceng/internal/_build/results?buildId=2657794&view=logs&s=380ab8c6-4139-55ff-15c4-fb48260f4dca&j=ba23343f-f710-5af9-782d-5bd26b102304 |
| bool setAutomaticDecompression, | ||
| string projectName = null, | ||
| string versionOverride = null) | ||
| private HttpClient CreateAzdoClient(string tokenOverride = null) |
There was a problem hiding this comment.
huh - somehow I missed - my bad.
Pipeline artifacts were not supported previously, due to differences in how the download URL needs to be determined and constructed. This was blocking at least a partial move of the VMR onto pipeline artifacts, and generally a move onto pipeline artifacts for .NET overall. To fix this, I've implemented support for both. The system will first use the artifact API to determine what the artifact type is, then construct a helper for future usage to obtain a download url given a file name.
To double check: