Jenkins Gitea-Plugin: Cannot scan private repositories

[FastFelix771]

• Gitea version (or commit ref): 1.4.0
• Git version: 2.17
• Operating system: Alpine Linux 3.7.0 virt-hardened
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant

Description

Hi,
I have a problem with the Gitea-Jekins Plugin.
https://github.com/jenkinsci/gitea-plugin

It can only scan public projects of any organization.
I have a JenkinsCI user on my Gitea Instance which is Member of the Owner Group of the Organization.

In Jenkins i use the Credentials of the JenkinsCI user and the Scan runs successful - but reports "0 repositories found".
Without the credentials of the JenkinsCI user, i get HTTP 401 from Gitea - as expected.
But for some reason, i need to make a repository public to be visible to the repository scanning... which is bad for internal projects...

Is there any way to workaround this behaviour?
The GitHub Repo of the Plugin itself doesn't have Issues activated, sadly.

Gitea Organization Scan Log:

[Sun Apr 22 15:20:10 CEST 2018] Starting organization scan...
[Sun Apr 22 15:20:10 CEST 2018] Updating actions...
[Sun Apr 22 15:20:11 CEST 2018] Consulting Gitea Organization

Checking repositories...

0 repositories were processed
[Sun Apr 22 15:20:11 CEST 2018] Finished organization scan. Scan took 0.63 sec
Finished: SUCCESS

[FastFelix771]

Feeling kinda ignored ._.

I don't know where else i could submit my issue, since the Plugin Author deactivated the ability and the Jenkins forums doesn't seem to provide their Issue Track for plugins anymore.
I followed some links of older issues related to the plugin and landed mostly on landing pages and 404 pages.

[thehowl]

Sorry about that! I guess most of us aren't really able to help because we've never used Jenkins (with Gitea at least). The fact that this may well not be an issue related to gitea directly does not help.

[FastFelix771]

I expected quite a lot people using Jenkins.
Which one is the recommended / most popular CI that can integrate with Gitea?

I'm not sure if it may be an issue of Gitea itself, too - i don't know the API (yet).
Maybe it is the expected behavior to hide private repositories of organizations from API users? Or maybe there is a special "flag" that needs to be sent alongside the request to include private repositories?

[thehowl]

Which one is the recommended / most popular CI that can integrate with Gitea?

Drone integration is quite good: http:https://docs.drone.io/install-for-gitea/

Maybe it is the expected behavior to hide private repositories of organizations from API users? Or maybe there is a special "flag" that needs to be sent alongside the request to include private repositories?

If anything, no access token is being passed so the repos aren't shown for that reason. But I don't know whether the plugin supports them 🤷‍♂️ Here is the documentation for the endpoint: https://try.gitea.io/api/swagger#/organization/orgListRepos

[FastFelix771]

Thanks for the docs - reading them right now.

The access token is probably not the problem, because if i don't configure the credentials of my JenkinsCI user in the CI Job Config, Gitea responds with 401 instead of returning public projects.

Hm, i will take a look at the plugin's source (again) and try to find a hint why it behaves like this.

[FastFelix771]

After looking for help on the discord server, I've found a solution.
AND I am sure now, this is a bug related to Gitea itself.

The scanning works if i set the Jenkins User as Gitea Admin.
So it is something about the privileges when getting the repositories of an organization.

The Jenkins User is in the Owner group of the Organization, so it actually should work without giving it global admin rights.

[ghost]

I have the same problem, but the workaround with admin user does not change anything

[FastFelix771]

What does the Log of the Repository Scan report? (Jenkins' side)

[rsiggi]

I am also sure, this is a gitea bug. Here are the steps to reproduce:

1. Create a new Account on https://try.gitea.io/
2. Login and create a new Organisation
3. Change to this Organisation
4. Create a new Repository for this Organisation

Now I see at https://try.gitea.io/ under "my repositories" the new repository owned by the organisation.
But if I use https://try.gitea.io/api/swagger#/organization/orgListRepos (with authorize on top and change Schemes to HTTPS), After "try it out" - I doesn't see the new repository. The response body is empty.

[ghost]

I'm having the same issue here, too.

Jenkins: 2.121.1 (dockerized running on jenkins/jenkins:lts-alpine)
Gitea Plugin: 1.0.8
Gitea: f4b7b42 (dockerized running on gitea/gitea:latest)

For me, the admin workaround is fine at the moment ... unfortunatelly the admin account has access to all repositories - so everybody who has permissions to create jobs can possibly find out about private repositories that they should not see normally :(

[bturmann]

I can confirm the issue with Gitea / Jenkins and also the workaround.

As mentioned by @rsiggi this is easy to reproduce on https://try.gitea.io/.

Using the API to get the repos of an org returns no results:
https://try.gitea.io/api/swagger#/organization/orgListRepos

Nevertheless, you can get details of an individual repo by providing the org and repo name:
https://try.gitea.io/api/swagger#/repository/repoGet

Hope that helps to narrow down the bug.

[bturmann]

May I suggest to change the title of this issue, e.g.:

API/issues: orgListRepos does not return private repos without admin permissions / Jenkins Gitea-Plugin: Cannot scan private repositories

[kacian]

I had same issue.
The workaround is to promote gitea user to administrator.

[Ryonez]

This is present in Gitea Version: 1.11.0. Looks like the fix is only targeted at 1.6

[mdegel]

I'm experiencing the same issue with the following version:
1.12.0+dev-276-g9789e0ad5 built with GNU Make 4.2.1, go1.13.7 : bindata, sqlite, sqlite_unlock_notify

[lafriks]

Please reopen new issue with description on how to reproduce such issue

[mrlov]

I'm experiencing the same issue with the following version:
1.11.3