[
https://issues.apache.org/jira/browse/NIFI-16560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-16560:
------------------------------------
Fix Version/s: 2.13.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> GitLab Flow Registry Client should not follow renames when listing flow
> versions
> --------------------------------------------------------------------------------
>
> Key: NIFI-16560
> URL: https://issues.apache.org/jira/browse/NIFI-16560
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Flow Versioning
> Reporter: Pierre Villard
> Assignee: Pierre Villard
> Priority: Major
> Fix For: 2.13.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The GitLab Flow Registry Client lists the versions of a flow by calling the
> commits API filtered by the flow file's path. Since GitLab 18.10, this
> endpoint follows file renames by default ({{{}follow=true{}}}), using rename
> detection based on content similarity. For flow files that were never
> renamed, this can produce false positives: commits that only modify a
> different, similar flow file are returned as versions of the requested flow
> (see gitlab-org/gitlab#382081). These unrelated commits then appear in the
> list of versions and can be selected when changing version.
> Flow files managed by the registry client are identified by the flow
> identifier and are not renamed, so following renames is not needed. This
> change adds {{follow=false}} to the commits request. GitLab versions before
> 18.10 ignore the parameter. The gitlab4j API does not currently expose this
> option, so the request is built with explicit query parameters.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
