Why Jenkinsfile changes Are Not Reflected in PR Build

Article ID:227246367
1 minute readKnowledge base

Issue

  • When a user modify the Jenkinsfile and opens a PR, the build does not take the changes into account

  • Console logs shows one of the following depending on the GitHub Branch Source plugin version:

    // GitHub Branch Source: 1.4-1.7
Loading trusted files from target branch at $REVISION_BASE rather than $REVISION_HEAD
// GitHub Branch Source: 1.8+:
Loading trusted files from base branch $BRANCH_NAME at $REVISION_BASE rather than $REVISION_HEAD

  • Branch Indexing shows

    [...]
Checking pull request #PR-1
      ‘Jenkinsfile’ exists in this pull request
    Met criteria
    (not from a trusted source)
[...]

Environment

Resolution

This is because the author of the Pull Request is not trusted. In this case Jenkins falls back to the Jenkinsfile of the base branch.

Changing the Jenkinsfile is equivalent to changing the job configuration. Only users with a certain level of trust should be allowed to do it.

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 they are trusted, otherwise they are not.

Therefore there are 2 ways to handle this:

  • Give push access (i.e. Write permission) to the PR author on the repository in GitHub

  • Explain to users that changing the Jenkinsfile requires a certain level of permission in GitHub

Links

This article is part of our Knowledge Base and is provided for guidance-based purposes only. The solutions or workarounds described here are not officially supported by CloudBees and may not be applicable in all environments. Use at your own discretion, and test changes in a safe environment before applying them to production systems.