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

PR build can use PR's head/merge Jenkinsfile insted of master branch.

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      In PR build, Jenkins says

      Loading trusted files from base branch master at [master HEAD] rather than [PR HEAD]

      I understand this behavior.(for security)
      but I want the option that use 'untrusted file' for try new build/jenkinsfile without brake the master branch.

        Attachments

          Issue Links

            Activity

            Hide
            michaelneale Michael Neale added a comment -

            You can do this by doing a PR from a branch in the same repo - which I think is a better way to honour the intent of the security model of github. Right?

            Show
            michaelneale Michael Neale added a comment - You can do this by doing a PR from a branch in the same repo - which I think is a better way to honour the intent of the security model of github. Right?
            Hide
            mapi ma pi added a comment -

            I found that Jenkins use merged Jenkinsfile if PR owner is contributor.
            When I opened this issue, I was organization admin, but was not contributor.
            this issue was not valid. sorry!

            Show
            mapi ma pi added a comment - I found that Jenkins use merged Jenkinsfile if PR owner is contributor. When I opened this issue, I was organization admin, but was not contributor. this issue was not valid. sorry!
            Hide
            myoung34 marc young added a comment -

            This seems to be an issue, or is poorly documented.

            I'm currently a member of the stratasan organization: https://github.com/stratasan
            I'm a member, but on a private repo I'm an Admin with all permissions, but I always get:

            Loading trusted files from base branch master at 096b02cbb8144a042bd6a5519eac8ccd6cd8e39f rather than e03a3ebc1c4584f16757ac4f80856b4c905bb28a

            We have protected branches (require status checks) on master, so I cannot push there, but I have permissions to all other branches.
            It's also a PR from a branch within the same upstream (not a fork)

            Show
            myoung34 marc young added a comment - This seems to be an issue, or is poorly documented. I'm currently a member of the stratasan organization: https://github.com/stratasan I'm a member, but on a private repo I'm an Admin with all permissions, but I always get: Loading trusted files from base branch master at 096b02cbb8144a042bd6a5519eac8ccd6cd8e39f rather than e03a3ebc1c4584f16757ac4f80856b4c905bb28a We have protected branches (require status checks) on master, so I cannot push there, but I have permissions to all other branches. It's also a PR from a branch within the same upstream (not a fork)
            Hide
            mapi ma pi added a comment -

            Even if you are an administrator, you must be listed here.
            https://github.com/ORGANIZATION/REPO/settings/collaboration

            Show
            mapi ma pi added a comment - Even if you are an administrator, you must be listed here. https://github.com/ORGANIZATION/REPO/settings/collaboration
            Hide
            rawler Ulrik Mikaelsson added a comment -

            I too have problems with this.

            I am in fact listed under collaboration. I have write-access to the repository as a whole through several policies, and I have tried to add my user directly to repo as a collaborator. Both branches in the PR are in the same repo, and I can write to both.

            I still get the error

            Show
            rawler Ulrik Mikaelsson added a comment - I too have problems with this. I am in fact listed under collaboration. I have write-access to the repository as a whole through several policies, and I have tried to add my user directly to repo as a collaborator. Both branches in the PR are in the same repo, and I can write to both. I still get the error
            Hide
            myoung34 marc young added a comment - - edited

            Ditto

            I am an admin of the organization on github, member of both 'members' and 'admin'
            On the private repo both of those groups have write access.
            The PR is on the same origin as the branch to merge into.
            I'm listed as collaborator on that repo.

            I still get the error.

            The bigger issue is that all of these tickets say "you need to be a collaborator". Outside of the fact that being a collaborator still produces the issue, that statement should not be the only way to do this, it should be the minimum.

            According to the docs (https://go.cloudbees.com/docs/cloudbees-documentation/cje-user-guide/):

            (such as pull requests filed by people not authorized to push to the main repository

            And the docs here (https://go.cloudbees.com/docs/support-kb-articles/CloudBees-Jenkins-Enterprise/Why-Jenkinsfile-changes-Are-Not-Reflected-in-PR-Build.html):

            Jenkins handles it that way: when changes to the Jenkinsfile are committed to a PR , Jenkins asks GitHub whether the PR author has the permission to push to the origin repository, if yes he is trusted, otherwise he is not.

            These are not true based on what we're being told.

            What were told about being a collaborator means that admins/members of an org cannot build PR's without extra steps (collaborator per all the replies). This is not effective.
            As an admin, we add a new user, put them in a group and let them do their thing. This is an equivalent trust. having to add them as a 'collaborator' on every repo is a pain and prone to mistake. Say we have 100 repos and add a new member or admin. We must go to each repo (or even at the org level but I dont think you can be labeled a collaborator there - only per repo) and add them there too. Forgetting to do that (which everyone will since this documentation is hard to find and not standard practice) means that someone will open a PR to change the Jenkinsfile and it will use the base branches with a single line warning in the build. That line is very easy to miss, so it will get merged and possibly break the next builds because of a syntax error.

            According to the docs, asking github whether they can push to the origin is good, but requiring them to be a collaborator is not.

            As an admin, I have access to push to that repo so i should be able to use my Jenkinsfile.
            As any member with org permissions (member, etc) I have access to push to that repo because the PR is on the same origin as the base branch, so this alone is enough to trust it, group permissions or not. You cannot create a PR from two branches without write access to that origin, so this alone should be enough to use the Jenkinsfile.

            Show
            myoung34 marc young added a comment - - edited Ditto I am an admin of the organization on github, member of both 'members' and 'admin' On the private repo both of those groups have write access. The PR is on the same origin as the branch to merge into. I'm listed as collaborator on that repo. I still get the error. The bigger issue is that all of these tickets say "you need to be a collaborator". Outside of the fact that being a collaborator still produces the issue, that statement should not be the only way to do this, it should be the minimum. According to the docs ( https://go.cloudbees.com/docs/cloudbees-documentation/cje-user-guide/): (such as pull requests filed by people not authorized to push to the main repository And the docs here ( https://go.cloudbees.com/docs/support-kb-articles/CloudBees-Jenkins-Enterprise/Why-Jenkinsfile-changes-Are-Not-Reflected-in-PR-Build.html): Jenkins handles it that way: when changes to the Jenkinsfile are committed to a PR , Jenkins asks GitHub whether the PR author has the permission to push to the origin repository, if yes he is trusted, otherwise he is not. These are not true based on what we're being told. What were told about being a collaborator means that admins/members of an org cannot build PR's without extra steps (collaborator per all the replies). This is not effective. As an admin, we add a new user, put them in a group and let them do their thing. This is an equivalent trust. having to add them as a 'collaborator' on every repo is a pain and prone to mistake. Say we have 100 repos and add a new member or admin. We must go to each repo (or even at the org level but I dont think you can be labeled a collaborator there - only per repo) and add them there too. Forgetting to do that (which everyone will since this documentation is hard to find and not standard practice) means that someone will open a PR to change the Jenkinsfile and it will use the base branches with a single line warning in the build. That line is very easy to miss, so it will get merged and possibly break the next builds because of a syntax error. According to the docs, asking github whether they can push to the origin is good, but requiring them to be a collaborator is not. As an admin, I have access to push to that repo so i should be able to use my Jenkinsfile. As any member with org permissions (member, etc) I have access to push to that repo because the PR is on the same origin as the base branch, so this alone is enough to trust it, group permissions or not. You cannot create a PR from two branches without write access to that origin, so this alone should be enough to use the Jenkinsfile.
            Show
            myoung34 marc young added a comment - Fixed code in https://github.com/jenkinsci/github-branch-source-plugin/pull/109
            Hide
            jglick Jesse Glick added a comment -

            Probably a duplicate of JENKINS-40652, just an accidental regression.

            The more general issue of nuanced behavior is JENKINS-36240, which I have a fix for but it relies on experimental APIs.

            Show
            jglick Jesse Glick added a comment - Probably a duplicate of JENKINS-40652 , just an accidental regression. The more general issue of nuanced behavior is JENKINS-36240 , which I have a fix for but it relies on experimental APIs.

              People

              Assignee:
              kohsuke Kohsuke Kawaguchi
              Reporter:
              mapi ma pi
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: