ServiceFabric CompressPackage

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

Hi Mike,

Thanks for reaching out, and I am sorry that you are running into this issue.

So I have just tried this using my own setup, and it seems to work.

Are you able to send me your raw task log?
And also the process json file?

Also, I did some reading and there is -ApplicationPackageCopyPath setting that you can override to configure the path to use , see, but I am not sure how would we set it!