Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix flakiness in Azure Functions (#6524)
## Summary of changes Attempt to fix flakiness in Azure Functions multi-sample build ## Reason for change #6472 added multi-version building for Azure Functions samples. Unfortunately, this caused the build stage to be flaky, because Azure Functions apparently generates and builds a [completely separate _.csproj_](Azure/azure-functions-dotnet-worker#1252). Unfortunately, it also ignores all the artifact output stuff, which means when we restore/build multiple versions of the app (with different api versions, it stomps over itself. e.g. we can see the sample app build itself doing the right thing: ``` 08:59:05 [DBG] Samples.AzureFunctions.V4Isolated -> /project/artifacts/bin/Samples.AzureFunctions.V4Isolated/release_net6.0_1.6.0/Samples.AzureFunctions.V4Isolated.dll 08:59:06 [DBG] Samples.AzureFunctions.V4Isolated -> /project/artifacts/publish/Samples.AzureFunctions.V4Isolated/release_net6.0_1.6.0/ ``` But there's also the "WorkerExtensions" thing which is going completely off the rails, ignores all of the Directory.Build.props etc and just does its own thing ``` 08:59:07 [DBG] WorkerExtensions -> /tmp/oh4iajvh.kcj/publishout/ 08:59:07 [DBG] WorkerExtensions -> /tmp/zv30zzl2.cxz/publishout/Microsoft.Azure.Functions.Worker.Extensions.dll 08:59:08 [DBG] WorkerExtensions -> /tmp/zv30zzl2.cxz/publishout/ ``` Unfortunately, this shows it's trying to build two separate versions to the same location, and things break. ## Implementation details My initial attempt in #6521 failed. In this attempt I split the v1 SDK and v2 SDK into two separate projects. The SDK versions are tracked separately. I was thinking that as long as we only build a _single_ version per project we _should_ be ok. It was not OK. So in the end I tore out the Azure Functions version tracking. We could/should consider adding it back in some way, but right now this is causing too many issues An alternative is to just remove the Azure Functions samples from the "auto-updating multi version". I kept the split between v1 and v2 of the Azure Functions SDK to give us a _little_ more coverage; I think it's about the best we can do. ## Test coverage If this all finally passes, we should be good. ## Other details An important thing to note is that _currently_, even though we will now get dependabot notifactions about updates to the azure functions libs, these _aren't_ tested automatically. That's because currently our testing on Windows does _not_ run the "multi version" tests like we do on Linux. And we _only_ test Azure functions on Windows. This is something I'd like to address longer term with PRs like #6498, but for the meantime, we'll need to manually keep the samples up to date with the latest SDK version when there's a dependabot PR
- Loading branch information