Its def a new cool venture for us too. Trying to work out a process that works. Right now, we have 10 Ignition environments ans setting up a push to a git branch representing the environment (combination of location and dev/test/prod) to Azure DevOps. Hopefully from there were hoping to do pull requests across branches to do promotions, but haven’t defined that process fully yet. Then once we figure that part out, use Azure pipelines to execute a pull on the target servers when the Pull Request is merged in, essentially fully automating deployments.
Your summary is right, changing a parent project causes the Update to fire on all the children projects. This makes sense from a Ignition execution point of view as the “parent” code has changed, but from a source control perspective only the parent project “changed”. Perhaps split the update or add a flag into the update to be able to know if the change was from the current project or triggers from a parent project update so the commit could be ignored. Perhaps similar to event scripts, the project update script has an event object with more details about the event to be able to use in scripting. This could avoid some of the complexities of doing things like reading the manifest.