We use Jenkins multibranch git jobs for various branches, some of them are open, allowing any user to directly push source code. However, our master branch follows a closed policy, permitting code merges only through a PR with successful unit tests run.
This approach generally works well, except for one specific scenario:
There are some cases with updates in both Jenkinsfile and source code which are interdependent. An old Jenkinsfile might not build updated source code, and vice versa. The problem arises when we create a PR from a branch with such interdependent updates to the master branch. The triggered build on the master branch continues to use its old Jenkinsfile, which then tries to build the updated source code from the PR branch — leading to build failures.
Is there a way to make the master branch use the Jenkinsfile from the PR branch to avoid this issue?
Note: That's what the entire process looks like. Participants:
Azure Repos GitAzure DevOps Pipeline. The setup is in the first imageJenkins multibranch job. The setup is in the second image
Whenever a user attempts to create a pull request for their changes into the master branch of Azure Repos Git, it initiates the execution of an Azure DevOps pipeline. This pipeline is relatively straightforward; its sole purpose is to trigger a Jenkins multibranch job. Subsequently, the Jenkins multibranch job is executed. If it successfully completes, we proceed to perform the actual merge of the pull request.
A challenge arises in this process: The Azure DevOps Pipeline is set up to trigger the master branch, which means it always triggers the execution of the Jenkinsfile located in the master branch, rather than the one in the PR branch. However, it's important to note that the Jenkins job, in the Declarative: Checkout SCM step, checks out the changes from the PR branch. That makes the build inconsistent - we have master's Jenkinsfile and pull request branch's source code.
Azure Devops pipeline configuration
Jenkins multibranch job configuration
