Azure-pipelines-tasks: UpdateServiceFabricAppVersion and Deploy compressed packages fails

[MikkelHegn]

See her: https://github.com/Azure/service-fabric-issues/issues/444

When using the UpdateServiceFabricAppVersion to only update changed package in combination with deploying compressed package, the deployment fails.

Cause seems to be that the compressed package is created at each deployment, which causes the checksum of the package to change (because of timestamps) - see the referenced task for more info.

How can these two tasks in combination support this scenario? Is it e.g. possible to run some tasks in a release definition dependent on the outcome of a task in a build definition?

[bishal-pdMSFT]

Currently there is no way possible to pass any info from build to release apart from artifact.

There are three options available:

1. Add support in deploy task to update all manifest versions if compress option is enabled

2. Enhance "UpdateType" drop-down to have "enable compression". if selected, it will update all versions.

3. Leave it to users to not select "Updated only if changed" if they want to compress while deploying.

Option #2 seems good to me as it limits the tasks updating manifest package. However #1 should also be possible if we re-factor existing code.

[bishal-pdMSFT]

@MikkelHegn

[MikkelHegn]

The problem with option 2 - is that you tied your build to your release - which I don't think is a good practice. Any build should be able to go to any cluster.

[bishal-pdMSFT]

This is not strictly tying up build and release. The build can still be deployed to any cluster - it however can mean that application version will always be bumped up.
I see your concern, but unfortunately there is no good solution from VSTS side. Should not this issue rather be tackled at SDK level where compression is actually happening?

[MikkelHegn]

According to this: https://github.com/Azure/service-fabric-issues/issues/382 We can actually compress the package as part of build. Let me try that configuration and see if that can fix this flow.

[dbreshears]

@MikkelHegn, right now package compression is specified in the publish profile which certainly seems incorrect. Compression should be done at packaging time and not during publish. We will look into this and the necessary property to disable if on by default

[Tadimsky]

Any update on this? I just hit this issue too and couldn't figure out what was happening.
I ended up having to disable compression from the PublishProfile by removing:
- <CopyPackageParameters CompressPackage="true" />

[dbreshears]

There is a PR out right now for this https://github.com/Microsoft/vsts-tasks/pull/5962

[bishal-pdMSFT]

PR #5962 is merged. It should be rolled out publicly in a couple of weeks.