FIX JENKINS-63048

[mecseid]

Based on go-gitea/gitea#9452, fix https://issues.jenkins-ci.org/browse/JENKINS-63048

[yylin1]

Hi @mecseid,

I have the same problem with the JENKINS-63048 ticket, wait for this PR update.
The Gitea API will limit Jenkins scan gitea organization(only scan top10 repositories).

Try your workaround, able default page size in the gitea config (app.ini) is not work.

[api]
DEFAULT_PAGING_NUM = 500

[mecseid]

Hi @yylin1,

Based on the Gitea documentation, the workaround should be work.

What version are you using?
v1.12.0 changelog:

* Use DEFAULT_PAGING_NUM instead of MAX_RESPONSE_ITEMS in ListOptions (#11831) (#11836)
* Honor DEFAULT_PAGING_NUM for API (#11805) (#11813)

So, I think, before v1.12.0, you have to set MAX_RESPONSE_ITEMS parameter.

[yylin1]

Hi @mecseid,

I'm using gitea version: 1.12.0+rc1 with docker, so we update gitea image to 1.12.5 will work.

Set the parameter in the gitea config (app.ini) via

[api]
DEFAULT_PAGING_NUM = 500
MAX_RESPONSE_ITEMS = 50

Scan Gitea Organization Log:

#previous 

...
10 repositories were processed
[Thu Oct 28 16:10:07 CST 2020] Finished organization scan. Scan took 7.2 sec
Finished: SUCCESS

#now

....
  18 repositories were processed
[Thu Oct 29 14:54:12 CST 2020] Finished organization scan. Scan took 12 sec
Finished: SUCCESS

Thank you for your quick response.

BTW, so this gitea-plugin PR issue will update in the new gitea version? (v1.13.0)

[mecseid]

As far as I know, this plugin doesn't follow the release schedule of gitea.
I didn't see any related breaking change in v1.13.0 release notes, so I think it will be work after the merge.

[zeripath]

The related PR was unfortunately merged into 1.12 - so this has been present for a while.

[zombified]

When is the next release of this project planned, and is this PR going to be apart of that release?

[mecseid]

When is the next release of this project planned, and is this PR going to be apart of that release?

Sorry @zombified but I don't have so much information about the next release date (and when this PR merged to master).
Please contact with @stephenc about more information.

[justusbunsi]

Thanks @mecseid for these changes. I am successfully using them for quite a while now through a fork of this repository. It works pretty well and none of my branches/tags are missing anymore. 👍

Unfortunately those changes reveal some performance issues with the currently used API endpoints. Given the fact that /api/v1/repos/{org}/{repo}/branches is paged, the plugin has to get 400 branches for repository via 8 requests (based on 50 items per response) on each repository indexing and if I am correct on webhook retrievals as well. In my particular environment I noticed that all those requests run approximately 2 seconds before getting the response from Gitea. Fetching tags via /api/v1/repos/{org}/{repo}/tags is not paged and takes up to 30 seconds for ~800 tags during webhook receives and repository indexing. This is an example for a quiet workday; on heavy workloads in Gitea it takes ages and affects the experience in Gitea itself.
To be fair, it might just be my environment. Who knows.

I dived into the Gitea API and found two possible alternatives for these endpoints.

• Branches: /api/v1/repos/{org}/{repo}/git/refs/heads (~100ms)
• Tags: /api/v1/repos/{org}/{repo}/git/refs/tags (~120ms)

Both alternative endpoints are not paged and I think they return the necessary dataset that is needed at that point of the plugin logic. Since switching to another API endpoint clearly is not scope of this PR, I've opened an issue at Jenkins JIRA to discuss a change and other possible redesigns that might increase plugin performance. But I thought I share my experiences with you over here. Maybe there are some possible changes to reduce the workload. 🤷

[lafriks]

I think this fixed now in #31, please reopen if not