i know that when we export xml as template, ids are not preserved (what we have on canvas vs on generated temp[ate xml). I wonder about ids from deployment from nifi registry are they preserved ?
Best Regards, *Emanuel Oliveira* On Tue, Feb 25, 2020 at 8:57 PM Kevin Doran <kdo...@apache.org> wrote: > I’ve always thought along the lines Otto suggests, that eventually, given > some way of formatting the diff, there would also be some visual tool in > the ecosystem that would help visualize that diff and could be used > specifically in the context of reviewing/merging changes. > > Lots of good discussion on this thread, thanks all! > > Kevin > > On Feb 25, 2020, at 15:44, Otto Fowler <ottobackwa...@gmail.com> wrote: > > -or- when diffing, some other representation could be presented other than > straight xml. > > The diff ( if run / visualized in nifi ) needn’t be byte for byte, it can > be logical can’t it? > > On February 25, 2020 at 14:58:24, Eric Secules (esecu...@gmail.com) wrote: > > Hi Ken, > > >> 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. >> > > I agree, doing PR can be improved by starting up a nifi instance and > registry on top of the feature branch, so you can view the changes in a > safe environment before approving. But this doesn't solve the issue of > merging diverged versions. For that we'd need a visual representation of a > diff. Maybe entering a 3 way diff mode with side-by-side canvases and no > active processors where the differences are highlighted. Doing merge > resolution at the XML level is a non-starter for me. > > I've tried out restarting the registry which works for receiving new > changes. I have also had some trouble with loosing previous version history > when restarting a registry, but the main issue would still be merging > diverged branches. Maybe it would help to have some checkout mechanism and > return to the days of centralized version control if merging is too > difficult to implement. > > -Eric > > On Tue, Feb 25, 2020 at 9:36 AM Ken Swanson <kswan...@1904labs.com> wrote: > >> 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 >> > >
