Jannik Rebmann created NIFI-16391:
-------------------------------------

             Summary: GitLabRepositoryClient: limit commit listing to the first 
page instead of paging the full history
                 Key: NIFI-16391
                 URL: https://issues.apache.org/jira/browse/NIFI-16391
             Project: Apache NiFi
          Issue Type: Improvement
          Components: Flow Versioning
    Affects Versions: 2.12.0
            Reporter: Jannik Rebmann


h4. Summary
{{GitLabRepositoryClient.getCommits(path, branch)}} uses the gitlab4j {{List}} 
overload, which internally delegates to {{{}Pager.all(){}}}. As a result, every 
call pages the *entire commit history* for the path (the client sets 
{{{}per_page=100{}}}). The commit listing should be bounded to the first page 
using a small, fixed page size ({{{}COMMIT_PAGE_SIZE{}}}).
h4. Environment / Observation
 * Self-hosted GitLab, many versioned process groups.
 * High volume of GitLab REST API calls ({{{}repository/commits{}}}) 
originating from NiFi.
 * Each individual {{getCommits(...)}} call is itself several page requests, 
because the full history is paged through.

h4. Root Cause
The use of {{Pager.all()}} in the GitLab client causes full-history paging on 
every call. The complete history is not required to determine the latest 
version or the version listing; the relevant commits are on the first page.
h4. Proposed Solution
 # In {{{}GitLabRepositoryClient.getCommits(path, branch){}}}, replace the 
{{{}Pager.all(){}}}-based overload with a call bounded to the first page.
 # Introduce a {{COMMIT_PAGE_SIZE}} constant with a small value (hard-coded 
initially; promotion to a property is an optional follow-up).
 # This bounds both the number of page requests per call and the payload size.

h4. Notes / Relationship
 * Mirrors the listing limit from {*}NIFI-14837 / PR #10186{*}, which was 
applied only to {{{}GitHubRepositoryClient{}}}; GitLab does not have this limit 
yet.
 * *Out of scope:* This issue covers only the bounding of the commit listing in 
the GitLab client. Removing the per-process-group multiplier (TTL cache in 
{{{}AbstractGitFlowRegistryClient{}}}) and the optional {{(commitSha, path)}} 
content cache are *not* part of this ticket.
 * The SHA→commit-detail cache from PR #10186 is not relevant for GitLab, 
because the gitlab4j commit listing returns fully-populated {{Commit}} objects.

h4. References
NIFI-14837, PR [https://github.com/apache/nifi/pull/10186]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to