[
https://issues.apache.org/jira/browse/NIFI-16526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-16526:
----------------------------------
Status: Patch Available (was: Open)
> GitLab Flow Registry Client should use the file's last commit to determine
> the latest version
> ---------------------------------------------------------------------------------------------
>
> Key: NIFI-16526
> URL: https://issues.apache.org/jira/browse/NIFI-16526
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
> Reporter: Pierre Villard
> Assignee: Pierre Villard
> Priority: Major
>
> The GitLab Flow Registry Client determines the latest version of a flow by
> taking the first result of the commits API, filtered by the flow file's path
> (GET /projects/:id/repository/commits?ref_name=<branch>&path=<file>). On some
> GitLab.com repositories, this endpoint has been observed returning commits
> that do not modify the requested path. The flow is then reported as out of
> date, with another flow's commit as the latest version. Importing the latest
> version fails with "Path or Branch not found", and the version conflict check
> on commit compares against the wrong commit.
> For the same repository, branch and path, the Repository Files API returns
> the correct last_commit_id.
> This change adds a getLatestCommitSha method to GitRepositoryClient. By
> default it uses the first commit returned by getCommits, so other providers
> behave as before. AbstractGitFlowRegistryClient uses it when determining the
> latest version and when checking for version conflicts. The GitLab
> implementation reads last_commit_id from the Files API, which also replaces
> the commits-list request on each sync with a single file metadata request.
> Listing versions still uses the commits API.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
