We have the issue that multiple developers are developing in parallel. That causes many little bootstrapping warnings, specifically about conflicting order-befores and duplicate UUIDs.
But everything is fine after the bootstrapping. So my first thought to fixing this (instead of going through everything in the YAML files manually) was to force another autoexport of the afflicted nodes. That would write the new, valid configuration to the files.
How can I force an autoexport? Or is there another solution to my problem that i’m overlooking?
1 Like
Are we talking content or configuration? Configuration differences will always be reloaded from the sources, unless you have bootstrap set to false, but then autoexport won’t work either. Content has the repository as source of truth, so if you start an updated repo against a project without that content I think auto export will synchronize the content…but I’m not 100% on this and their may be subtleties why this won’t work perfectly.
So, basically not really. Other solutions basically entail not having people work in the same part of the config, but this isn’t really practical in many cases.
We have a known issue with auto-export generating incorrect order-before statements for content (not for config). This is a super tricky thing to get right (and sometimes impossible), because it’s essentially a 3-way diff with one source unknown. In almost every case, the order of content nodes doesn’t actually matter in practice, with a notable exception being HST site menu nodes. If this is the case for you, you will see warnings like this:
WARN [org.onehippo.cm.engine.ConfigurationContentService.warnForDuplicateOrderBefores()
My recommendation would be to adjust your log4j config to ignore these warnings in development, but also take special care to review HST site menu nodes before committing to your source control.
As for duplicate UUIDs, this is a much less common problem and likely to be sensitive to the specific conditions of your project. Often this is caused by copy-paste of an existing YAML file that contains UUIDs, since duplicates are unlikely to occur at random. You might consider bulk-removing the jcr:uuid property from the relevant YAML files, unless you actually reference nodes by ID, e.g. in a hippo:docbase property elsewhere. Since references to UUIDs that have been duplicated are ambiguous by nature, an automated fix cannot be guaranteed to be correct – you’ll have to check and fix any such references yourself using context.
You can also use the /hippo:configuration/hippo:modules/autoexport/hippo:moduleconfig/autoexport:filteruuidpaths property to suppress the export of UUIDs in the first place. This won’t help you if UUIDs have already been copy-pasted, though.
As for your direct question, the answer depends on if you’re referring to HCM “config” or “content”. Content is always fully re-exported, replacing the entire YAML source file, whenever any change is made to a node within the source file or any ancestor node. The order-before problem is likely to recur, though, since it was caused by a known bug.
Config is only updated incrementally, adding or rewriting individual properties as they change or appending child nodes as they are added. Since there’s no (official) way to change a node’s UUID, auto-export would never rewrite this specific property for a node managed as config.
1 Like
I have another use for forcing an auto-export of config. After upgrades or even after some config files have been hand edited or written by hand the yaml formatting can be a bit different than what the auto-export module would generate. When a developer changes a config that had not been fully generated through the auto-export module through the CMS console then the format sometimes changes for that individual value (ex. multi value properties). Instead of having this noise show up in day to day work it would be nice, for example after an upgrade, to have some way to force the configuration files to be fully re-exported. This would also help cases where the default export file structure has changed over time so that we can make old configuration conform to new auto-export standards.