NIFI-14555 - Option to empty parameter values in git registry clients

[pvillard31]

Summary

NIFI-14555 - Option to empty parameter values in git registry clients

The goal of this PR is to add an optional property for all Git based registry clients. The property "Empty Parameters" will default to false to retain current behavior. If set to true, all values of all parameters will be removed before the flow is being versioned and stored in the git repo.

Parameters are usually environment dependent and it might not be desirable to include in the versioned flow the parameters values that have been set in a lower/dev environment while designing the flow.

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 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 mvn clean install -P contrib-check
  • JDK 21

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 @pvillard31, the general concept sounds useful. As I often comment on Boolean properties, this might be better expressed as an enumeration like Parameter Context Values with options of Retain and Remove, with Retain being the default option. Perhaps there aren't other options, but raising it for consideration. What do you think?

[pvillard31]

Thanks @exceptionfactory - good point, adjusted the code

[exceptionfactory]

Thanks for adjusting the approach @pvillard31. I noted one more recommendation to use an enum implementing DescribedValue for the definition, then this should be ready to go.

[exceptionfactory]

Instead of using AllowableValue, it would be helpful to define this as an enum, there the enum name can be the value itself, as opposed to the lowercase retain and remove. This also makes the property retrieval cleaner with asAllowableValue().

[pvillard31]

Thanks @exceptionfactory - pushed a commit to use an enum instead

[exceptionfactory]

Thanks for the updates @pvillard31, I pushed a small change to use the enum name() instead of an additional String value, aligning with other enum values. I plan to merge following a successful build.