I use Jenkins with a multibranch pipeline and I want the pipeline to be executed when there is
a PR from any branch to dev
a commit to any release/** branch
But I cannot get the configuration to discover the commits. My configuration is:
Which I thought would do:
Take all commits in dev and release/** and all PRs to those branches.
What it actually does: only commits on dev and release/**, all PRs are ignored.
What do I have to change?
Related
Currently I have configured in the Jenkins multibranch pipeline so that dev, stage, uat and prod branches get indexed. When I'm creating PRs from any feature branch to the dev branch, only dev branch gets indexed which is correct, but when I do a PR from dev to stage, for example, both the stage and dev branches are getting indexed which shouldn't happen, only the target branch stage should get indexed, without source branch dev.
My current configuration looks like this:
What should I change so that always only the target branch to which PR is merged to is going to get indexed? In my example, only stage branch, when the PR is coming from dev?
After a bit more testing I have noticed that the dev branch gets crossed out when a PR is created to the stage branch and after approval of PR and merge the dev branch is not crossed out anymore. This action is detected in Jenkins as if the branch is newly added and there for it indexes the branch again.
The solution was to set the Discover branches Behaviour to All branches. That prevented 'excluding' the dev branch from discovery and therefore the branch doesn't get indexed again after the PR merge.
I have a project in Bitbucket with setup web-hook and Jenkins multibranch project.
Web-hooks work okay for the branches, that are already scanned and are presented in the multi-branch project: when the PR is created for any of them, the build is triggered - ok.
But when a PR is created for a new branch (which is not in the list of scanned branches yet), the Scan multibranch pipeline is not triggered and the branch does not appear in the list.
I have the following configuration for the job:
The questions are:
Why that scan procedure is not triggered on a PR for new branch with the options from above?
How can I set this scan trigger strategy directly in the pipeline jenkins file?
By default, Jenkins multibranch pipeline discovers branches of my GIT repository. It can execute the related Jenkinsfile for the target branch. However, this design force me to create one version of Jenkinsfile for one branch and this cause Jenkinsfile maintenance overhead.
If I can ensure I will have only 1 version of Jenkinsfile, is it possible for multibranch pipeline to point to such Jenkinsfile instead of referencing Jenkinsfile of the target branch?
I'm using Jenkins on a CI environment, with the plugin for SVN.
The build polls SCM every minute for new changes, and triggers if there are any.
The problem is that we need to change from one branch to another with regularity.
When this happens, the correct branch is checked out, but jenkins continues polling the old branch.
What do I have to do for it to always poll the correct branch?
EDIT:
With multibranch pipelines, it will create a sub-job for each branch. We can do the polling by just adding
triggers {
pollSCM('* * * * *')
}
under 'pipeline' on the jenkinsfile. Now these sub-jobs will not need to change branch, because there is one for each branch. This avoids the issue I was having before.
If you are using Jenkins 2, it is recommended to use the multibranch pipeline, along with jenkinsfile in the SVN repository
I am not sure if I am asking the question in right way.
When I am triggering the multi branch pipeline job and I do "checkout scm" in Jenkinsfile, does it checkout the pull request or Master + pull request?
It depends of your settings.
As I remember, multibranch pipeline builds pull requests in separated view and it can build as PR source branch and result of PR. It cloned your repo, checkouts target branch, merges source branch into it and runs your stages.
If you look at the logs you will see that it checks out the hash of the commit
example: git checkout 1fb651dfdcbea276627de0247bbf5047840cae4c
As for workspace, if you log in to the Jenkins machine where this is running you will see that each branch has a separated workspace. Here you will find the source code of the checked out branch. The separated workspace ensures that there is no conflict when working with multiple concurrent branch builds.