• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • gitea-plugin
    • None
    • Gitea 1.16.1
      Jenkins 2.319.3
      Plugin-Version 1.4.1

      I created an organisational folder for a private Gitea instance. Both the organization and the project are private.

      The user and the personal-access-token are created as described on the plugin help page.

      While build branches work fine, building pull-requests fails with an error if I start the build manually. Builds triggered by Webhooks run fine.

      Started by user Gregor Tudan
      Running as Gregor Tudan
      Looking up repository VV/antora-theme
      Querying the current revision of pull request #17...
      Current revision of pull request #17 is b8cf059e793da04596f6b9e63a88410866eb23ad
      org.jenkinsci.plugin.gitea.client.api.GiteaHttpStatusException: HTTP 403/Forbidden
      	at org.jenkinsci.plugin.gitea.client.impl.DefaultGiteaConnection.getObject(DefaultGiteaConnection.java:865)
      	at org.jenkinsci.plugin.gitea.client.impl.DefaultGiteaConnection.fetchRepository(DefaultGiteaConnection.java:200)
      	at org.jenkinsci.plugin.gitea.GiteaSCMFileSystem$BuilderImpl.build(GiteaSCMFileSystem.java:170)
      	at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:293)
      	at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:106)
      	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:310)
      	at hudson.model.ResourceController.execute(ResourceController.java:99)
      	at hudson.model.Executor.run(Executor.java:432)
      [Gitea] Notifying pull request build status: FAILURE There was a failure building this commit
      [Gitea] Notified
      Finished: FAILURE

      Here is what's in the jenkins logs:

      022-02-15 10:25:53.110+0000 [id=6686]  INFO    o.j.p.g.GiteaNotifier$JobScheduledListener$1#run: Looking up repository VV/antora-theme
      2022-02-15 10:25:53.157+0000 [id=6686]  INFO    o.j.p.g.GiteaNotifier$JobScheduledListener$1#run: Querying the current revision of pull request #17...
      2022-02-15 10:25:53.231+0000 [id=6686]  INFO    o.j.p.g.GiteaNotifier$JobScheduledListener$1#run: Current revision of pull request #17 is b8cf059e793da04596f6b9e63a88410866eb23ad
      2022-02-15 10:25:53.231+0000 [id=6686]  INFO    o.j.p.g.GiteaNotifier$JobScheduledListener$1#run: Notifying pull request pending build VV/antora-theme/PR-17
      2022-02-15 10:25:53.295+0000 [id=6686]  INFO    o.j.p.g.GiteaNotifier$JobScheduledListener$1#run: VV/antora-theme/PR-17 Notified
      2022-02-15 10:25:53.320+0000 [id=7658]  INFO    o.j.p.workflow.job.WorkflowRun#finish: VV/antora-theme/PR-17 #1 completed: FAILURE

      This is the failed call in the access log:

      /api/v1/repos/VV/antora-theme

          [JENKINS-67807] Fail to fetch PR from private org

          Steven added a comment -

          Please update Gitea to the latest stable release and try again. There were some API fixes which most likely fix your issue.

          Steven added a comment - Please update Gitea to the latest stable release and try again. There were some API fixes which most likely fix your issue.

          Gregor Tudan added a comment - - edited

          Hi Steven, thanks for looking into this! I'm already running the latest version of Gitea (1.6.1 1.16.1)

          Gregor Tudan added a comment - - edited Hi Steven, thanks for looking into this! I'm already running the latest version of Gitea ( 1.6.1 1.16.1)

          Steven added a comment -

          Latest version would be 1.16.x. https://github.com/go-gitea/gitea/releases. How have you installed Gitea?

          Steven added a comment - Latest version would be 1.16.x. https://github.com/go-gitea/gitea/releases . How have you installed Gitea?

          Gregor Tudan added a comment -

          Sorry, that was a typo. I'm running 1.16.1 on Linux (amd64) with the binary straight on bare metal.

          Gregor Tudan added a comment - Sorry, that was a typo. I'm running 1. 16 .1 on Linux (amd64) with the binary straight on bare metal.

          Steven added a comment -

          Ah, ok. Thanks for the clarification. Two additional questions:

          • How is your Jenkins configured to run builds, i.e. have you defined a specific access control for builds?[
            https://www.jenkins.io/doc/book/security/build-authorization/]
          • When looking at the Gitea request logs, do you see whether basic or token authentication was used for this request?
            TBH, I am not sure if the plugin always uses token authentication or basic authentication in some rare cases. The API endpoint only allows token authentication.

          Steven added a comment - Ah, ok. Thanks for the clarification. Two additional questions: How is your Jenkins configured to run builds, i.e. have you defined a specific access control for builds?[ https://www.jenkins.io/doc/book/security/build-authorization/ ] When looking at the Gitea request logs, do you see whether basic or token authentication was used for this request? TBH, I am not sure if the plugin always uses token authentication or basic authentication in some rare cases. The API endpoint only allows token authentication.

          Gregor Tudan added a comment - - edited

          I looked at the config - our jenkins is configured to run the build as the user who triggered it. This might actually make a difference. I guess the Webhook triggers the build as System-User while manually triggered jobs use a different one? My credentials (access token) for Gitea have the visibility "global". 

          The Gitea router-logs don't show which kind of authentication was used. Could you give me a quick hint on how I can enable the right logging? 

          Gregor Tudan added a comment - - edited I looked at the config - our jenkins is configured to run the build as the user who triggered it. This might actually make a difference. I guess the Webhook triggers the build as System-User while manually triggered jobs use a different one? My credentials (access token) for Gitea have the visibility "global".  The Gitea router-logs don't show which kind of authentication was used. Could you give me a quick hint on how I can enable the right logging? 

          Gregor Tudan added a comment - - edited

          I reproduced the issue on a clean instance. It has something to do with the Authorize Project-Plugin.

          https://plugins.jenkins.io/authorize-project/

          Assume the following setup:

          • Gitea-Plugin and Instance configured
          • the Gitea Access-Token is in the global credentials
          • Setup a project using the branch source plugin 
          • Install the Authorize Project Plugin
          • Configure the Authorization Level in Global Security

          This triggers the exception above. It does not seem to matter which authorization level you choose - the exception is thrown as soon an there is an authorization strategy. This still only happens on pull-requests, and if they are triggered using the Jenkins UI. Branches and Pull-Requests triggered by a webhook work fine.

          I went through the code and debugged how the credentials lookup works in the GiteaSCMFileSystem - if authorization is enabled, the credentials lookup always returns null. It's still a mystery to me why this works with the branches...

          If we look at how other branch source plugins handle this, we see that they don't use the actual user authentication, but rely on ACL.SYSTEM.

          Github-Branch-Source: https://github.com/jenkinsci/github-branch-source-plugin/blob/b2f51293cb78fef3005faf129760fecef24c75bc/src/main/java/org/jenkinsci/plugins/github_branch_source/Connector.java#L321

          Gitlab-Branch-Source: https://github.com/jenkinsci/gitlab-branch-source-plugin/blob/7101b1c0def994b8083e48aaad21d29cd04585e0/src/main/java/io/jenkins/plugins/gitlabserverconfig/servers/GitLabServer.java#L250

          So I guess that's the way to go...

          Gregor Tudan added a comment - - edited I reproduced the issue on a clean instance. It has something to do with the Authorize Project-Plugin. https://plugins.jenkins.io/authorize-project/ Assume the following setup: Gitea-Plugin and Instance configured the Gitea Access-Token is in the global credentials Setup a project using the branch source plugin  Install the Authorize Project Plugin Configure the Authorization Level in Global Security This triggers the exception above. It does not seem to matter which authorization level you choose - the exception is thrown as soon an there is an authorization strategy. This still only happens on pull-requests, and if they are triggered using the Jenkins UI. Branches and Pull-Requests triggered by a webhook work fine. I went through the code and debugged how the credentials lookup works in the GiteaSCMFileSystem - if authorization is enabled, the credentials lookup always returns null. It's still a mystery to me why this works with the branches... If we look at how other branch source plugins handle this, we see that they don't use the actual user authentication, but rely on ACL.SYSTEM. Github-Branch-Source: https://github.com/jenkinsci/github-branch-source-plugin/blob/b2f51293cb78fef3005faf129760fecef24c75bc/src/main/java/org/jenkinsci/plugins/github_branch_source/Connector.java#L321 Gitlab-Branch-Source: https://github.com/jenkinsci/gitlab-branch-source-plugin/blob/7101b1c0def994b8083e48aaad21d29cd04585e0/src/main/java/io/jenkins/plugins/gitlabserverconfig/servers/GitLabServer.java#L250 So I guess that's the way to go...

          Gregor Tudan added a comment -

          Gregor Tudan added a comment - Here is a PR for the issue: https://github.com/jenkinsci/gitea-plugin/pull/61

            gtudan Gregor Tudan
            gtudan Gregor Tudan
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: