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

Set visible flag when Jenkinsfile is taken from a trusted revision rather than PR head

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Minor Minor
    • pipeline

      When pull requests are done from private repos in a github organization, for example: A develop will fork a repo, commit some changes then submit a pull request from the forked repo. In that case the files will be taken from organization instead of developer, so the tests actually run on the wrong code, they pass and the pull request in github gets marked as passing even though it was never actually tested.

      A way to know if the revision of the Jenkinsfile is not the same than the branch tip (a.k.a the Jenkinsfile comes from an untrusted brach) should be great.

      https://github.com/jenkinsci/github-branch-source-plugin/blob/a10e869ec3b653b05eb188bd1e4054211d32294f/src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSource.java#L421-L433

          [JENKINS-34596] Set visible flag when Jenkinsfile is taken from a trusted revision rather than PR head

          Emilio Escobar created issue -
          Antonio Muñiz made changes -
          Component/s Original: github-branch-source-plugin [ 20858 ]

          A possible solution would be to add an environment variable to env in SCMBinder#create.

          Antonio Muñiz added a comment - A possible solution would be to add an environment variable to env in SCMBinder#create .
          Jesse Glick made changes -
          Link New: This issue is blocking JENKINS-33256 [ JENKINS-33256 ]
          Jesse Glick made changes -
          Summary Original: Add a way to know if the revision of the Jenkinsfile is not the same than the branch tip New: Set visible flag when Jenkinsfile is taken from a trusted revision rather than PR head
          Jesse Glick made changes -
          Labels New: multibranch

          Jesse Glick added a comment -

          My plan is a little different: introduce a readTrusted step which would work without a checkout, retrieve the contents of a named file from the repository, and either load from the designated commit, if it were trustworthy, or fail if it were not.

          The case of failing a PR build in case the (untrusted) submitter modified Jenkinsfile would thus reduce to starting the (origin) Jenkinsfile with

          readTrusted 'Jenkinsfile'
          

          (ignoring the return value). But it could be used for other purposes too.

          Jesse Glick added a comment - My plan is a little different: introduce a readTrusted step which would work without a checkout, retrieve the contents of a named file from the repository, and either load from the designated commit, if it were trustworthy, or fail if it were not. The case of failing a PR build in case the (untrusted) submitter modified Jenkinsfile would thus reduce to starting the (origin) Jenkinsfile with readTrusted 'Jenkinsfile' (ignoring the return value). But it could be used for other purposes too.

          introduce a readTrusted step which would work without a checkout

          How is that going to work with GitSCMSource?

          Antonio Muñiz added a comment - introduce a readTrusted step which would work without a checkout How is that going to work with GitSCMSource ?
          Jesse Glick made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]

          Jesse Glick added a comment -

          Like Jenkinsfile itself, it uses a private workspace pending JENKINS-33273. Of course GitSCMSource does not implement getTrustedRevision so using this step would be pointless with that SCM source: all origin branches are trusted anyway.

          Jesse Glick added a comment - Like Jenkinsfile itself, it uses a private workspace pending JENKINS-33273 . Of course GitSCMSource does not implement getTrustedRevision so using this step would be pointless with that SCM source: all origin branches are trusted anyway.
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-33273 [ JENKINS-33273 ]

            jglick Jesse Glick
            escoem Emilio Escobar
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: