Schemamismatch when configuring Modelsbuilder and Runtime locally

[HamDerAndrew]

Version

Deploy version: 12.0.4 CMS: 12.2.0

Issue

When configuring your Modelsbuilder and Runtime mode locally on a fresh project (v12 in this case) and push to the Cloud environment, you will hit a schemamismatch with the following configuration: appsettings.json:

      "ModelsBuilder": {
        "ModelsMode": "SourceCodeAuto"
      },

appsettings.Production.json:

      "Runtime": {
        "Mode": "Production"
      },
      "ModelsBuilder": {
        "ModelsMode": "Nothing"
      },

Issue was discovered when a customer reached out after following our docs: https://docs.umbraco.com/umbraco-cms/fundamentals/setup/server-setup/runtime-modes

Steps to reproduce

1. Create a fresh v12 project on Cloud
2. Clone down the Live environment
3. On your local clone in the appsettings.Production.json add the following Runtime and Modelsbuilder settings:

     "Runtime": {
       "Mode": "Production"
     },
     "ModelsBuilder": {
       "ModelsMode": "Nothing"
     },

4. Also on your local clone in appsettings.json add the following Modelsbuilder setting:

     "ModelsBuilder": {
       "ModelsMode": "SourceCodeAuto"
     },

5. Remove the following code from the csprojfile:

   <RazorCompileOnBuild>false</RazorCompileOnBuild>
   <RazorCompileOnPublish>false</RazorCompileOnPublish>

6. Run the project locally and create a document type and template.
7. Create a content node that uses your document type and template.
8. Commit your code and schema changes and push them to Live
9. Content transfer your content node to Live. You should hit a schemamismatch now for your content node:

---

This item has been added to our backlog AB#35067

[ronaldbarendse]

I was able to reproduce this and in my case the schema deployment didn't add the templates to the document types (although the UDA files had the correct values). After clearing the Deploy signatures and updating the schema, the document types had the correct templates assigned and the schema mismatch was fixed...

So for now, you can try clearing the signatures and updating the schema as a workaround. I'll have to further investigate why this happens in the first place, but having Umbraco:CMS:Runtime:Mode set to Production does prevent editing templates from the backoffice, so that might be related...

[alina-tincas]

I can confirm it is happening on v13 as well

https://github.com/umbraco/Umbraco.Deploy.Issues/assets/83591955/b6ac570a-07a2-482d-a4de-b2f1fb983c95

[alina-tincas]

after some further testing, if

"Runtime": {
    "Mode": "Production"
  },

is removed from appsettings.Production.json and then generate models from backoffice locally, then the content is transferred successfully

https://github.com/umbraco/Umbraco.Deploy.Issues/assets/83591955/c3f325ba-3efe-458b-8bbe-13313f785580

[ronaldbarendse]

After some additional testing, I've found the root cause of this issue 🥳 When processing the template__*.uda artifacts and the template doesn't exist yet, Deploy creates it via IFileService.SaveTemplate() without initially setting the path to the template file. This caused it to update those same UDA files again on the environment that these schema changes were pushed to, resulting in the schema mismatch...

After correctly setting the path when the initial template is saved, this doesn't happen anymore. I haven't completely researched why this was only happening when the runtime mode was set to Production, but I guess the other modes do some additional processing that causes it to re-save the template with the correct path (and thereby automatically fixing the schema mismatch again)... Regardless of that, processing artifacts shouldn't update them to something different, so we've ensured this is fixed in 4.10.0, 10.4.0, 12.2.0 and 13.1.0 (all scheduled for release next Tuesday).