Deployment for Service Fabric service version upgrade fails on VSTS Release

6
votes

Summary

The following error appears at log.

The content in ConfigPackage Name:Config and Version:1.0.0.20180315.2 in Service Manifest 'TwoServicePkg' has changed, but the version number is the same.

I changed only the code of one of the services, so I changed only one version of the code in the manifest.

In this case, there is no problem with the upgrade through Visual Studio.

However, upgrading via VSTS will cause the above error.

Details

I created VSTS CI/CD for Service Fabric as default. (Pipeline: VSTS Git Repo -> Build -> Release)

First 'Commit > Build > Release' is Okay.

Service Fabric Manifest Versions

MyAppType: 1.0.0
  OneService: Pkg 1.0.0 / Code 1.0.0 / Config 1.0.0
  TwoService: Pkg 1.0.0 / Code 1.0.0 / Config 1.0.0

Now, I fix OneService Code only. And Edit verisons of service fabric manifest.

Service Fabric Manifest Versions

MyAppType: 1.0.1(*)
  OneService: Pkg 1.0.1(*) / Code 1.0.1(*) / Config 1.0.0
  TwoService: Pkg 1.0.0 / Code 1.0.0 / Config 1.0.0

Second Commit > Build is Okay. But Release is Failed. The following error appears at log.

The content in ConfigPackage Name:Config and Version:1.0.0.20180315.2 in Service Manifest 'TwoServicePkg' has changed, but the version number is the same.

But I didn't modify TwoService Pkg (Both Code, Config).

Moreover, It's good to Publish To 'Azure Cloud Service Fabric Cluster' through VS2017 IDE, Immediately. (Of course, 'Upgrade the Application' option checked.)

Current temporary solution is to version up all (all pkg / code / config) like below.

Service Fabric Manifest Versions

MyAppType: 1.0.1(*)
  OneService: Pkg 1.0.1(*) / Code 1.0.1(*) / Config 1.0.1(*)
  TwoService: Pkg 1.0.1(*) / Code 1.0.1(*) / Config 1.0.1(*)

I want to construct build pipeline, But It's Confusing.

Additional Information

I just use default VSTS Service Fabric template.

And modify only Publish Profile name (Cloud.xml -> Cloud.Development.xml).

Release Task Screenshot Release Task Screenshot

1
azureazure-devopsazure-service-fabricazure-pipelines-release-pipeline
How does your VSTS build pipeline look like, which tasks are you using and how are they configured? – Ivan G.
Thank you for your attention. I added screenshot. – Minos
Can you share detail build log on the OneDrive? (set system.debug variable to true, then queue build and share this log) Can you reproduce this issue with the new project? If so, you can share sample project on the OneDrive. – starian chen-MSFT
Check whether it is related to deterministic compiler flag: stackoverflow.com/questions/49236009/… – starian chen-MSFT
@starianchen-MSFT I used the default template and confirmed that the option was already turned on. There is nothing special about the project. The service fabric example in github also produces the same error. But in your answer, I have some information and it seems to be helpful. Thank you for the reply. – Minos

1 Answers

5
votes

The error you get as the error message suggest :

'The content in ConfigPackage Service Manifest 'PackageName' has changed, but the version number is the same.

That means: we found something different in this package that does not match the previous version, because you've said the version should be the same, they should match, so I don't know what to do and will let you fix that.

The message is not very suggestive, so at first glance you get lost.

I have answered the same questions here error-while-upgrading-azure-service-fabric-through-vsts-ci-cd, please check if the answer help you solve your problem.

I will explain a bit more:

Whenever you register an application, service fabric will compare the new version being registered with the versions currently in the server, if the same service version is already there, it will compare the packages, the config packages, the code package and so on, if any of them doesn't match it will fail the deployment.

Every small change on any of these, should trigger a version upgrade, for example, if you add or remove a config setting in the Setting.xml you have to upgrade the version of your config file and one in the service manifest.

Before:

app1 -------> 1.0.0
  service1 -> 1.0.0
    code ---> 1.0.0
    config -> 1.0.0

After

app1 -------> 1.0.1
  service1 -> 1.0.1
    code ---> 1.0.0
    config -> 1.0.1

For the code package the same happens, and if you upgrade the code and config at same time, you should only upgrade the service manifest only one version, like:

app1 -------> 1.0.1
  service1 -> 1.0.1
    code ---> 1.0.1
    config -> 1.0.1

The trickiest challenge here are the code changes, whenever a new build is triggered, the build will download the source and compile everything, you know what has changed based on commit changes, but for the build everything will generate an assembly, so it does not care if it changed or not, it will generate a new assembly, despite the code being the same from previous build the output binary on most of the times will be different.

Going through the Application Registration, if the version keep the same, these binaries should match the existing ones, what is not gonna happen. To solve this, the differential packaging join the party, I won't give too much details here because is out of scope for this answer, but you can get more information on these links:

Service Fabric Application with a diff package

StackOverflow Question: Differential Packaging