Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jenkins Gitea-Plugin: Cannot scan private repositories #3829

Closed
2 of 7 tasks
FastFelix771 opened this issue Apr 22, 2018 · 17 comments
Closed
2 of 7 tasks

Jenkins Gitea-Plugin: Cannot scan private repositories #3829

FastFelix771 opened this issue Apr 22, 2018 · 17 comments

Comments

@FastFelix771
Copy link

  • 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
Copy link
Author

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
Copy link
Contributor

thehowl commented Apr 26, 2018

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
Copy link
Author

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
Copy link
Contributor

thehowl commented Apr 26, 2018

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

Drone integration is quite good: http://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
Copy link
Author

FastFelix771 commented Apr 26, 2018

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
Copy link
Author

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
Copy link

ghost commented May 9, 2018

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

@FastFelix771
Copy link
Author

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

@rsiggi
Copy link

rsiggi commented May 22, 2018

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
Copy link

ghost commented Jul 2, 2018

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
Copy link

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
Copy link

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
Copy link

kacian commented Nov 16, 2018

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

inxonic added a commit to inxonic/gitea that referenced this issue Nov 22, 2018
techknowlogick pushed a commit that referenced this issue Nov 23, 2018
#3829) (#5383)

Signed-off-by: Daniel Balko <inxonic+github@gmail.com>
inxonic added a commit to inxonic/gitea that referenced this issue Nov 23, 2018
…vate repos with read access (go-gitea#5310) (go-gitea#3829)

Signed-off-by: Daniel Balko <inxonic+github@gmail.com>
lafriks pushed a commit that referenced this issue Nov 24, 2018
…os with read access (#5310) (#3829) (#5393)

Signed-off-by: Daniel Balko <inxonic+github@gmail.com>
@Ryonez
Copy link

Ryonez commented Dec 10, 2019

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

@mdegel
Copy link

mdegel commented Feb 10, 2020

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
Copy link
Member

lafriks commented Feb 10, 2020

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

@mrlov
Copy link

mrlov commented Mar 18, 2020

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

@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants