Commit noise from Sitecore Content Serialization

Question

We are using Sitecore 10.1 with Docker, JSS, and the Content Serialization CLI on a new project and I feel like we must be doing something wrong as we get a lot of seemingly unimportant changes to the serialized files over and over and over. This makes it very difficult for the project lead to review the changes in a pull request.

My questions are:

• Are others seeing these same kinds of seemingly unimportant changes?
• Are we doing something wrong in using JSS, Content Serialization and git?
• Can we ignore these unimportant changes?
• Is there something we can do to reduce this noise in git commits?

Our typical work flow is:

1. Create new branch off of the develop branch.
2. Use dotnet sitecore ser push and jss deploy files to update the local CM server running in a Docker container with latest changes from other developers.
3. Create a new UI component using the JSS CLI, and create en.yml files in the \data\routes\ folder using the new component.
4. Test the new component in disconnected mode with jss start to run the http://localhost:3000/ server.
5. Use jss deploy app to install the new component and test route into the local CM server.
6. Test the new component running in the CM container and do further configuration in Sitecore (SXA settings, etc).
7. Run dotnet sitecore ser pull to serialize the Sitecore items and configuration changes.
8. Commit changes to git, push to origin, and submit a pull request.

Depending on the component there might be a dozen or so files legitimately added or updated to the source code. But after running 'dotnet sitecore ser pull' there are changes to hundreds of files that are unrelated to the component. For example:

   Hint: Blob
-  BlobID: "83dac2ef-0fb4-4314-8955-14c853ab83c6"
+  BlobID: "ec590271-0dbc-4fe2-bc22-2b35e3e5e594"
...
   Hint: __Revision
-  Value: "4589d9a3-01f3-4833-b886-9876da61f64b"
+  Value: "f7e52699-7b1b-4b23-a4f1-a0447bb9d73b"
...
   Hint: __Updated
-  Value: 20210909T215045Z
+  Value: 20210909T124928Z

This often happens to images even though the image wasn't changed. While the BlobID and __Revision fields get new GUIDs and the __Updated timestamp is changed, the actual Blob value doesn't change.

+  - ID: "52807595-0f8f-4b20-8d2a-cb71d28c6103"
+    Hint: __Owner
+    Value: |
+      sitecore\0w42dEaiZ8
+  - ID: "5dd74568-4d4b-44c1-b513-0af5f4cda34f"
+    Hint: __Created by
+    Value: |
+      sitecore\0w42dEaiZ8

I guess when the item is first created the __Owner and __Created by fields are not set, but somehow they are set later on and then serialized.

   Hint: thumbnailImage
   Value: |
-     <image alt="Switching Practices for Fidelity" mediaid="{B526628A-C31D-5358-AFAF-1582A55E2312}" />
+     <image mediaid="{B526628A-C31D-5358-AFAF-1582A55E2312}" alt="Switching Practices for Fidelity" />

It is possible that the order of these attributes are important, but I doubt it.

All of these extra changes make it difficult to review pull requests, resolve merge conflicts, and actually understand what changes are being made and committed to source control. It is very easy to miss a mistake in the code/content changes with all of this noise.

TIA for any solutions.

Answer 1

It looks like the Sitecore CLI and Sitecore Content Serialization are detecting changes in Owner, Created, and possibly some other system managed fields such as timestamping that is triggering a change detection.

In Sitecore CLI version 4.0.0 and Sitecore Management Services version 4.0.0 we introduced a new feature that will allow you to define Excluded Fields that will eliminate this "noise".

The Sitecore CLI is compatible with Sitecore 10.1, so I suggest upgrading these and setting up your excluded fields list.

This can be done globally (great for cases like system managed fields which apply to all content), and at a Module level.

Answer 2

I understand the concern in the comment. Adding here due to verbosity of the response.

Here's a scenario that we ran across with previous versions of the Sitecore CLI (versions 2.0.0, 3.0.0).

When creating content where a field is managed by a Standard Value, the serialization process ignores the field when empty/null/etc. This way, when the item is 'pushed' to Sitecore, the Sitecore kernel will use the Standard Value and not see a serialization value as a possible override for the given field.

That works great for nearly all cases.

However, there's a special condition for the CreatedBy and Owner fields. When these fields are empty/null and sent over to Sitecore during serialization the Sitecore kernel will automatically populate it with the current user. When the current user is different than the standard value user then serialization detects the unnecessary changes.

For example if the person who defined the standard value was 'sitecore/developerA' and the authenticated identity of the CLI user was 'sitecore/admin' ... then this would trigger the noise and false positive change detection.

Little challenging to articulate so if there's any questions on that let me know. I can attempt to elaborate.

I do not know if this is causing the 'noise' you are witnessing but I wanted you to be aware as it is a possible cause. If this is the case, using the excluded fields feature would eliminate the noise if you set it up for just the CreatedBy and Owner fields.

There may be a bug or defect with blob storage and our handling as well. If you can pinpoint the root cause and reproduce it I would love to know about it so that I can track and investigate for resolution. In general, you should not be seeing consistent and on-going false positive change detection.

For excluded fields in general, yes I agree in that I would not recommend specifying anything in the excluded fields list that is something that you want tracked as a real change.