I have a lot of interest in this too, as my team has run into these issues as well.
I feel like there are also issues in trying to build a pull-request-like workflow, in that most NiFi design is done visually on the canvas but there isn't a good way, that I know of, to represent differences between versions in a visual way. Even if you enabled pull request-like functionality, I don't know that I would expect users to approve changes by examining diffs in the XML files. However, I did have one thing to add that I hope might help: On Tue, Feb 25, 2020 at 12:32 AM Eric Secules <esecu...@gmail.com> wrote: > I've also tried backing up my local registry to a separate branch in git > and manually merging it with the branch that central-reg backs up to, but > these git branches are glorified backups and the registry doesn't seem to > be built to pull updates from them. On top of that doing a code review on > the generated JSON describing a process group is difficult and I ran into > several merge conflicts testing out a very simple merge where the target > branch diverged slightly from the feature branch. > >From what I've seen, the registry will use any updates that are in the repo when it starts up. So you should be able to do something like this: 1. Make the registry pull (or clone) from the backup as part of its startup process 2. Restart the registry when a merge to master is made. AFAIK this should not affect any NiFi instances that are connected to the registry; they should continue to work once the registry comes back up It's a bit clunky but I think it works. -Ken
