Mismatches when deploying content from local to live

[bjarnef]

I am migration a site from Umbraco v8 to v9 and cloned a clean Umbraco 9 project on Cloud.
Locally this it pointing to v8 database, generate revisions and deployed this, which are also extracted on the v9 project.

The revisions on local and live are identical, but I still get this error when deploying the content from local to live environment.

Strange enough this operation here seems to change the order of the dependencies compared to when I run echo > deploy-export or save from backoffice.

But I guess the order shouldn't matter.

One thing it that the two "Settings" element types mentioned in the error message both inherits background color and text color properties from a "Base Color Theme" element type, but I don't see why that should be an issue.

Regarding the templates I don't see any differences except Umbraco Cloud transform these to lowercase in /site/wwwroot/Views ... e.g. on local and in repository it is HomePage.cshtml, but homepage.cshtml in /site/wwwroot/Views

The error message doesn't tell anything about what the issue is and "See 'Mismatches' for details." isn't very helpful, when you check all revisions and confirm they are identical 😅

[bjarnef]

@AndyButland do you have an idea why it is causing these mismatches?

[bjarnef]

I un-checked the inherited composition from the two element types and added Background Color and Text Color properties directly to the setting element types instead. Before it inherited these from "Base Color Theme" element type.

It didn't use to be an issue, but many something in Deploy V9 that fails handling this?

Now I only have these template mismatches, but I can't figure out why?

[bjarnef]

Ohh, it seems like it may be a bug in Deploy v9.0.0, when templates has dependencies to a Master template.

I removed Master template for all these templates, pushed the revisions.. and now I can transfer the content to live/remote environment just fine 😲🤯

I haven't had this issue before with Deploy as far I recall only when there was mismatch on e.g. property or template aliases.

When I select Master template again for all templates, so I have this structure and deploy the revisions.

Afterwards I deploy again and get same error again:

[bjarnef]

@AndyButland @nul800sebastiaan I wonder if you guys could try if you can reproduce this error?

[bjarnef]

When I switch the the connection string from pointing on the v8 database, to point to the original LocalDB created when cloning the clean Umbraco Cloud V9 project (empty connection string), then I get same error when doing a full restore from the live environment which contain the content nodes previous transferred.

When I change the templates again to not use Master templates and has dependency to this, I can restore content and also transfer content to live/remote environment.

[jonat123]

@bjarnef I can confirm that I am seeing the same issue with the master template and content transfers, when migrating a V8 site to a V9 site, so this does indeed look like a bug.

[AndyButland]

Thanks both. I've been trying to replicate this, but unfortunately without success. Are either of you able to please validate what I'm doing to see if I'm missing something, or yourselves provide a set of steps, ideally for a single doc type/template to make it easier to diagnose, to trigger this issue please?

Here's what I've tried:

• On a V8 site running Umbraco Deploy, created a doc type with a template.
• Created another template and made that the master template for the first.
• Copied the 3 generated .uda files and the two .cshtml files into a local V9 environment, and triggered an extraction.
• Confirmed that I see the doc type and templates in the back-office as expected.
• Copied the .uda files and the .cshtml files into a destination V9 environment, and triggered an extraction.
• Created a content item based on the doc type in the local environment, and queued it for transfer.
• Successfully transferred the content item to the destination environment.

[bjarnef]

@AndyButland just a few thoughts.

Could you name the master template "Master" and with alias "Master". I didn't try renaming it to something else though.
Also ensure the content node has a template selected e.g. using "Home Page" which has dependency on "Master" template.

When I migrated the site I switched the connection string in the new cloned v9 install to target the existing v8 database and ran echo > deploy-export.

Then I deployed the revisions and templates to v9 Cloud project and checked the document types and templates existed on the remote environment.

Finally I deployed the content (still with connection string target in v8 database) to the v9 remote environment in this case just the live environment.
Then I got the mismatch error.

Otherwise let me know and I can grant you access to the Cloud project I am working on. Maybe you have access to more log files or can debug on the specific project?

[AndyButland]

Thanks - I can replicate this now having followed those steps. So now just need to figure out what's going on...

[AndyButland]

Some notes to keep track before breaking for lunch:

• This isn't consistent, but I have been able to see it with the setup described above:
  • Change template definitions on both sites so the template the document being transferred depends on doesn't have a master template - transfers OK.
  • Change template definitions on both sites so the template the document being transferred depends on does have a master template - fails with schema mismatch.
• When looking to debug, and having two local sites, one pointing to the same local database and the other two the same cloud database, I don't see an issue for either case.
• I do though when using the cloud site.
• Reviewing in the database can see the checksum saved in the signatures table differs in the local and cloud database, when we have a master template associated.
• When generating checksums using known json strings can see the resulting checksum differs due to the order of the dependencies (and we only have two when we have a master template defined, hence we don't see a problem when there is no master template).
• It doesn't look like dependencies are explicitly ordered, so perhaps we have a framework change here that previously (i.e. in V8) always serialized in the order added. But as we don't explicitly order, we can't guarantee that - and for some reason, running on Cloud we get one order, running locally we get another.
• A comment in the OP suggests there's other cases where we may get different orders.

[bjarnef]

@AndyButland it makes sense if the checksum is generated based on the order of the dependencies.
I noticed as original mentioned here #72 (comment) when I had run echo > deploy-export and pushed changed, but then afterward used "Extract Schema To Data Files" operation locally or echo > deploy-export on Cloud environment and pulled changes, it seems to switch the ordering of the template dependencies.

If I locally ran echo > deploy-export multiple times after it didn't seem to cause changes or if I triggered "Extract Schema To Data Files" operation multiple times.

[AndyButland]

I've created a PR to resolve this now - it's in CMS rather than Deploy though, and relates to differences in globalization settings between local Windows environment and that used in Azure Web Apps (and Umbraco Cloud).

[AndyButland]

Closing as this will be resolved with CMS release 9.0.1. Not tagging as it's a CMS release rather than a Deploy one.

[bjarnef]

@AndyButland I was wondering if is it possible as a workaround for now in Startup.cs to configurate default culture en-US, which I think is the default culture on Umbraco Cloud.
I tried something like this, but didn't seem to work :) https://stackoverflow.com/a/44888965/1693918

[AndyButland]

I don't think that'll help, as it's not just related to the default culture. It's related to this change, about which there's a blog post here.

If you look in the PR I created, Bjarke has made a comment which suggests an amend to your project file you could try now.

[bjarnef]

Okay, I see :)
I came across this https://docs.microsoft.com/en-us/dotnet/core/run-time-config/globalization and it seems there is something called runtimeconfig.json. I am not familiar with this though, so I am not sure when it is used.

I will give it a try using the suggestion from @bergmania

[ronmurp]

Had a similar schema mismatch problem today (trial account, U9 site).

With no content, push, pull, restore/transfer all worked ok - i.e. produce doc types in live or local doesn't matter.

Created a simple home page doc type with a composition, where composition contained a Page Title text string.

Creating content home page, either on local first, then transfer, or live first, then restore locally, ... schema mismatch.

Finally, removed composition from home page doc type, and added page title as a property. Then restores/transfers start to work. Adding more properties, locally or live, with push or pull, transfer or restore, all worked.

The composition seemed to be the problem.

[bjarnef]

@ronmurp yeah, I also had some mismatches when using block settings from base document type:
#72 (comment)

@AndyButland did you PR also fix this scenario?

[AndyButland]

I've just tested this scenario using the bits that will become 9.0.1 (of CMS and Deploy) and aren't seeing this issue related to compositions, so it's possible this was the same problem (with ordering of dependencies differing between Cloud and local).