NIFI-15673 - Add support for Author+Committer with git-based Flow Registry Clients

[pvillard31]

Summary

NIFI-15673 - Add support for Author+Committer with git-based Flow Registry Clients

Right now, in NiFi, when using a git-based Flow Registry Client, all commits are made with the identity that is configured for the authentication of the registry client. It means that if many users are using the same NiFi UI, all commits made by different users will be reported as being made with the same user (likely the service account used in the registry client configuration).

This is not ideal when working with multiple users and trying to distinguish who made the actual commits.

With the git-based implementations, it is possible to make a commit and specify both an author and a committer.

This change is to use the identity of the NiFi User connected in the UI as the author and use the identity configured in the registry client as the committer.

Important notes:

• the proposed implementation in GitHub is using reflection as a temporary workaround until a submitted improvement is accepted/merged/released (see Add support for specifying Author and Committer (issue #2199) hub4j/github-api#2200)
• if the NiFi User does not resolve to an email address, the identity won't be resolved on the git provider side and it will just show the author as an unkown user with just the NiFi identity
• I didn't see an option to do that with Bitbucket Data Center

This has been tested with GitHub, GitLab, Azure DevOps and Bitbucket cloud. See some screenshots below.

A potential follow-up improvement would be to show this information in the UI in the views where we list flow versions.

Screenshots

When my NiFi identity does NOT resolve to a user in the git provider:

GitHub

GitLab

Bitbucket (only the author is shown in the UI - see https://jira.atlassian.com/browse/BCLOUD-13836)

When my NiFi identity does resolve to a user in the git provider:

GitHub

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000
• Pull request contains commits signed with a registered key indicating Verified status

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• Build completed using ./mvnw clean install -P contrib-check
  • JDK 21
  • JDK 25

Licensing

• New dependencies are compatible with the Apache License 2.0 according to the License Policy
• New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

• Documentation formatting appears as expected in rendered files

[exceptionfactory]

Thanks for proposing this improvement @pvillard31.

There is certainly value is tracing the commit author, but as described and implemented, it requires the NiFi user identity to be an email address, which may not be the case in many situations. One possibility to attempting to determine if it is an email address.

Considering this from another perspective, what about adding some trailer to the commit message footer? One possibility is the common Co-authored-by. This still requires a name and email address for exact matching, but as a footer, it is more open to interpretation. The email could also be derived according to the Git service, such as username@users.noreply.github.com and username@noreply.gitlab.com. The approach only requires a NiFi username matching the Git service username. If it doesn't match, it is less of an issue.

I'm open to considering possible alternatives.

[exceptionfactory]

Another benefit of an approach based on the message footer is that it avoids the current reflection-based workaround.