Github user bbende commented on the issue:
https://github.com/apache/nifi-registry/pull/112
Been testing this and has been looking good so far...
I was doing a test where I configured to push to a remote, but I didn't
supply a username/password because I honestly wasn't sure if the push would
leverage my cached credentials at the OS level.
So the push failed with an exception like:
```
Caused by: org.eclipse.jgit.errors.TransportException:
https://github.com/bbende/nifi-versioned-flows.git: Authentication is required
but no CredentialsProvider has been registered
at
org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:522)
~[org.eclipse.jgit-4.11.0.201803080745-r.jar:4.11.0.201803080745-r]
at
org.eclipse.jgit.transport.TransportHttp.openPush(TransportHttp.java:435)
~[org.eclipse.jgit-4.11.0.201803080745-r.jar:4.11.0.201803080745-r]
at org.eclipse.jgit.transport.PushProcess.execute(PushProcess.java:160)
~[org.eclipse.jgit-4.11.0.201803080745-r.jar:4.11.0.201803080745-r]
at org.eclipse.jgit.transport.Transport.push(Transport.java:1344)
~[org.eclipse.jgit-4.11.0.201803080745-r.jar:4.11.0.201803080745-r]
at org.eclipse.jgit.api.PushCommand.call(PushCommand.java:169)
~[org.eclipse.jgit-4.11.0.201803080745-r.jar:4.11.0.201803080745-r]
... 109 common frames omitted
```
This makes sense, but the result was that the flow was committed to the
local repo, but because of the error when pushing, the error was thrown out of
the REST layer and the response to NiFi indicated that starting version control
failed. So it was left in a weird state where NiFi now thinks the process group
is not under version control, but the local repo does have the first version
saved.
Do you think we should catch any exceptions around the push inside the
persistence provider and log them, but maybe not throw an error?
That would leave things in a more consistent state, but I'm kind of torn
because then it may not be obvious to users that the pushes are failing unless
they look in the registry logs.
---
