We are using BE v13.2
We have an issue where changes made to anything (FTL or YAML) on the CMS are not being bootstrapped when using:
-Drepo.bootstrap=true
We tried…
-Drepo.bootstrap=full
… and this did get the changes. However, I don’t think this is the way forward.
Why would…
-Drepo.bootstrap=true
… not work?
Hi,
you can start your investigation by using the cms console, the nodes under /hcm:hcm will give you more insights. For example hcm:baseline@hcm:lastpudated contains the last update datetime. Moreover the children nodes will show what changes the system has bootstrapped. Also check the nodes where you expect to have a change, there’s an indication (HCM Origin) of which yaml file contibuted to create/update the node
HTH
Saimir
Thank you both for your replies.
Just to clarify, we only hit this issue after upgrading from version 11.2 to 13.2.
We have checked the hcm:basline and it shows the correct date.
Issue HCM-281 looks like we would need to upgrade again in order to resolve this problem?
Are there any dangers in using -Drepo.bootstrap=full as a temporary workaround?
“Full” bootstrapping not only persists configuration changes to the repository, it also wipes out manual configuration changes which have not been added to the project’s bootstrap data
System and content items will be safe. It may not be an issue, but that is something you will need to verify.
Thanks Jasper,
Other than System and Content, what else is there? Could you be more specific or provide an example just so we can test for ourselves?
Any changes made to configuration nodes through the console. Some plugins as well (such as settings management). Configuration nodes are only reloaded (normally) when the bootstrap changes compared to the baseline. Changes made in the console aren’t added to the baseline.
btw, I also suggest checking your startup logs for any errors when doing bootstrap=true. Any errors will mean no changes will be made.
See also:
Thanks Jasper - we couldn’t see any obvious errors.
It seems like the “full” flag might be ok in our case as we would never make any configuration changes outside of development and pass those up through the deployment pipeline.