Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-33256

Re-enable GitHub PR support for public repos

XMLWordPrintable

      GitHub PRs for public repos were disabled in the 1.3 release due to concerns about untrusted Jenkinsfiles. While that's understandable, the result is that, well, this doesn't build PRs any more unless you're using a private repo, and that's unfortunate to say the least. This is especially inconvenient for a GitHub Enterprise use case, since "public repos" doesn't mean the same thing there.

          [JENKINS-33256] Re-enable GitHub PR support for public repos

          Andrew Bayer created issue -
          Jesse Glick made changes -
          Remote Link New: This issue links to "workflow-plugin PR 244 (Web Link)" [ 14018 ]
          Jesse Glick made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Jesse Glick made changes -
          Remote Link New: This issue links to "scm-api-plugin PR 5 (Web Link)" [ 14019 ]

          Jesse Glick added a comment -

          Initial planned implementation: PRs to always be built; if the author of the PR has push permission to the origin repository (or, if this information is not easily available from GH, if they are a member of the same organization), build their Jenkinsfile as written; if not, use the Jenkinsfile from the target branch.

          Possible add-on: a way to determine from Jenkinsfile whether it is coming from the PR branch or the target branch. I am not sure there is a real use case for this, though.

          Jesse Glick added a comment - Initial planned implementation: PRs to always be built; if the author of the PR has push permission to the origin repository (or, if this information is not easily available from GH, if they are a member of the same organization), build their Jenkinsfile as written; if not, use the Jenkinsfile from the target branch. Possible add-on: a way to determine from Jenkinsfile whether it is coming from the PR branch or the target branch. I am not sure there is a real use case for this, though.
          Jesse Glick made changes -
          Labels New: api security workflow

          Manuel Recena Soto added a comment -

          I don't think this is a bug.

          Manuel Recena Soto added a comment - I don't think this is a bug.

          Andrew Bayer added a comment -

          Nah, it's definitely a bug, albeit one introduced for good reasons. =) Putting aside github.com public repo use cases, GitHub Enterprise behind-the-firewall use cases are basically all now broken, and "public" behind-the-firewall repos are basically equivalent to github.com private repos, so they shouldn't be restricted, IMO.

          Andrew Bayer added a comment - Nah, it's definitely a bug, albeit one introduced for good reasons. =) Putting aside github.com public repo use cases, GitHub Enterprise behind-the-firewall use cases are basically all now broken, and "public" behind-the-firewall repos are basically equivalent to github.com private repos, so they shouldn't be restricted, IMO.

          Andrew Bayer added a comment -

          And fwiw, I like the idea of being able to say "just use the Jenkinsfile from the target branch" without worrying about who the author is in most cases. Obviously, for PRs with legit changes to the Jenkinsfile, that's a bit different, but the majority of use cases, etc.

          Andrew Bayer added a comment - And fwiw, I like the idea of being able to say "just use the Jenkinsfile from the target branch" without worrying about who the author is in most cases. Obviously, for PRs with legit changes to the Jenkinsfile, that's a bit different, but the majority of use cases, etc.

          Manuel Recena Soto added a comment -

          abayer My initial proposal was to consider both private and public repos. In fact, thus is in 1.2. Anyway I'm sure we can find a better solutions. Thanks for your feedback.

          Manuel Recena Soto added a comment - abayer My initial proposal was to consider both private and public repos. In fact, thus is in 1.2. Anyway I'm sure we can find a better solutions. Thanks for your feedback.

            jglick Jesse Glick
            abayer Andrew Bayer
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: