We’ve been working with MS on an issue where we’ve seen blocks of slow deployment speeds but only to ServiceFabric clusters. A deploy to an Azure VM during that same time period seems to behave. One of the threads we’ve been pulling is that on the Service Fabric cluster, during a period of time where we see the slow speeds, they will see a count of 3943 files transferred (for one package) as opposed to 2237 for a non-slow time (same package).
Through this they have been recommending we add the flag -compresspackage to the copy-servicefabricapplicationpackage command. Which we did. However when we do that, we get a “0x80070005”. (E_AccessDenied). We finally took that same set of directories, hardcoded a path to a different “temp” directory (in the same tree structure that Octopus uses for temporary “work”) and it ran without issue. This feels like Octopus may have a lock on the directory structure that the SDK is trying to compress.
We are using Octopus v2018.8.8