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

Pullrequest github executes Jenkinsfile of origin branch

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      There 2 problems that's comes with this:

      PR's to a branch without Jenkinsfile but working branch has a Jenkinsfile are not executed by jenkins.
      ERROR: /var/lib/jenkins/workspace/<organision>_<repository>_PR-15-QN42E7GZF23RNDD3R6SOUQOVTDJI2IGDB4C7LFJ5M35IGM43I4XQ@script/Jenkinsfile not found
      
      PR's where a change has been made in the Jenkins file are still executing Jenkinsfile of origin branch.

        Attachments

          Issue Links

            Activity

            Hide
            lanwen Kirill Merkushev added a comment -

            seems its not a problem of github-plugin (it does nothing with jenkinsfile and PRs)

            Show
            lanwen Kirill Merkushev added a comment - seems its not a problem of github-plugin (it does nothing with jenkinsfile and PRs)
            Hide
            stephenconnolly Stephen Connolly added a comment -

            Both of these are intended behaviours.

            There are improvements to the behaviour planned under JENKINS-36240

            Currently, the github branch source attempts to differentiate between pull requests from users who have permission to commit directly to the origin repository and pull requests from randomers on the interwebs creating drive by PRs. The heuristics for detecting whether a given GitHub user is a collaborator can depend on the permissions that were granted to the API token used for scanning, so where that fails, the only PRs that can be assumed "safe" are those from the origin repository itself. JENKINS-36240 proposes to use a new (experimental) API from GitHub that will enable the easier test of asking GitHub "Hey is user jrandomerfromtheinterwebs allowed to commit directly to myorg/trusted-repo"

            So the plugin will then be able to decide if the PR is trusted or not trusted.

            When the PR is trusted (i.e. currently if from either an origin repo or from a user listed in the list of collaborators reported to the API token - which is known not to be the full list in a lot of cases) then the Jenkinsfile from the PR will be used.

            When the PR is not trusted then the Jenkinsfile will not be used, instead the Jenkinsfile from the target branch will be used and if that is missing, so be it.

            I have created JENKINS-41616 for the component of this request that is a legitimate bug, though not the bug you reported!

            Thank you very much for this report, as it has identified a bug

            Show
            stephenconnolly Stephen Connolly added a comment - Both of these are intended behaviours. There are improvements to the behaviour planned under JENKINS-36240 Currently, the github branch source attempts to differentiate between pull requests from users who have permission to commit directly to the origin repository and pull requests from randomers on the interwebs creating drive by PRs. The heuristics for detecting whether a given GitHub user is a collaborator can depend on the permissions that were granted to the API token used for scanning, so where that fails, the only PRs that can be assumed "safe" are those from the origin repository itself. JENKINS-36240 proposes to use a new (experimental) API from GitHub that will enable the easier test of asking GitHub "Hey is user jrandomerfromtheinterwebs allowed to commit directly to myorg/trusted-repo" So the plugin will then be able to decide if the PR is trusted or not trusted. When the PR is trusted (i.e. currently if from either an origin repo or from a user listed in the list of collaborators reported to the API token - which is known not to be the full list in a lot of cases) then the Jenkinsfile from the PR will be used. When the PR is not trusted then the Jenkinsfile will not be used, instead the Jenkinsfile from the target branch will be used and if that is missing, so be it. I have created JENKINS-41616 for the component of this request that is a legitimate bug, though not the bug you reported! Thank you very much for this report, as it has identified a bug

              People

              • Assignee:
                stephenconnolly Stephen Connolly
                Reporter:
                pjvanthof Peter Hof
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: