I am not sure which component this should be assigned to, please feel free to move it to right component.

      Pull request testing is important to our project, and we are currently using Github Pull request builder plugin https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin. However, this plugin has not be updated recently because it up for adoption.

      Blue Ocean team has been working on pull request feature and it would be key to have following features available for us to use the new PR feature.

      1. Pull request should not automatically start, it must be triggered by user in whitelist.
      2. Whitelist - Users with Commit access to the repo, specific org and specific users.
      3. Status check should be made for pending, building, finished.
      4. Pull request trigger should be able to request test and merge.
      5. Pull request testing should be aborted soon as new commit has been made to the PR.
      6. Pull request testing should be able to make comment on the PR once completed.
      7. Multiple trigger support for each repository.
      Example:
      Please test macOS
      Please test Linux
      Please test
      Please smoke test macOS.

      Here is example of what swift project does.
      https://github.com/apple/swift/blob/master/docs/ContinuousIntegration.md#pull-request-testing

          [JENKINS-42032] Support for Pull request testing by trigger

          mishal shah added a comment -

          Another reason why trigger base PR is important.

          https://twitter.com/paaleksey/status/833353340079706112

          "TIL: There are bots on Github that create pull requests to projects using CI replacing all code with bitcoin-mining code." - paaleksey

          mishal shah added a comment - Another reason why trigger base PR is important. https://twitter.com/paaleksey/status/833353340079706112 "TIL: There are bots on Github that create pull requests to projects using CI replacing all code with bitcoin-mining code." - paaleksey

          The issue here is that the rate limits may end up being significantly burned up checking for statuses.

          The current code only builds PRs from trusted contributors, which helps fight against the bots.

          Need to investigate if there are API cheap ways to pick up the PR status that are not prone to abuse (current thinking is perhaps to apply a label to request a build and have jenkins remove the label after a build is done)

          Stephen Connolly added a comment - The issue here is that the rate limits may end up being significantly burned up checking for statuses. The current code only builds PRs from trusted contributors, which helps fight against the bots. Need to investigate if there are API cheap ways to pick up the PR status that are not prone to abuse (current thinking is perhaps to apply a label to request a build and have jenkins remove the label after a build is done)

          Michael Neale added a comment -

          stephenconnolly they are currently using GHPRB which allows this it seems - so it isn't burning up API right now (that may be just luck?)

          Michael Neale added a comment - stephenconnolly they are currently using GHPRB which allows this it seems - so it isn't burning up API right now (that may be just luck?)

            Unassigned Unassigned
            shahmishal mishal shah
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: