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

Pullrequest github executes Jenkinsfile of origin branch

    XMLWordPrintable

Details

    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

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

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

            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

            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

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

              Dates

                Created:
                Updated:
                Resolved: