-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
Jenkins 2.235.2
Git plugin 4.3.0
When changing Branch Specifier setting ** with enabled 'poll SCM' trigger - polling somehow breaks.
Steps to reproduce:
- Create a pipeline job definition 'Pipeline script from SCM'
- Fill settings: SCM: GIT, repo url and credentials, Branch Specifier: * leave blank, *Script path: path to jenkinsfile, Lightweight checkout: disabled
- In 'Build triggers' section enable 'Poll SCM' and set schedule: 'H/2 * * * *'
Let's imagine your repo has two branches: master and feature/some.
After initial settings everything works fine: commits to any of branches trigger a new build.
Now next step:
- change Branch Specifier to r_efs/heads/master_ and commit to both branches
Build is triggered only on commit to 'master' branch - that's OK.
Now:
- change Branch Specifier back to blank value (or refs/heads/* or *)
Commit to both branches and see how build is triggered only on master branch.
Expected behavior was to trigger builds for both branches.
After several changes of this settings while trying to make it work again polling behaves even more strange - see log below:
Started on Jul 23, 2020 1:54:00 PM Using strategy: Default [poll] Last Built Revision: Revision 674414e49d0e7ad72fe66283c5000ab11c5a3ba0 (refs/remotes/origin/master) using credential ee777337-1339-4379-a06b-f2f480d3213f > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repositories > git config remote.origin.url ssh://...:2222/~dmitry.korotkov/sampleprojectsforjenkins.git # timeout=10 Fetching upstream changes from ssh://...:2222/~dmitry.korotkov/sampleprojectsforjenkins.git > git --version # timeout=10 using GIT_SSH to set credentials Ssh key to access ... > git fetch --tags --progress ssh://...:2222/~dmitry.korotkov/sampleprojectsforjenkins.git +refs/heads/*:refs/remotes/origin/* # timeout=10 Polling for changes in Seen branch in repository origin/dmitrykorotkov/Jenkinsfile-1595400745873 Seen branch in repository origin/master Seen 2 remote branches > git show-ref --tags -d # timeout=10 Using strategy: Default [poll] Last Built Revision: Revision 674414e49d0e7ad72fe66283c5000ab11c5a3ba0 (refs/remotes/origin/master) using credential ee777337-1339-4379-a06b-f2f480d3213f > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repositories > git config remote.origin.url ssh://...:2222/~dmitry.korotkov/sampleprojectsforjenkins.git # timeout=10 Fetching upstream changes from ssh://...:2222/~dmitry.korotkov/sampleprojectsforjenkins.git > git --version # timeout=10 using GIT_SSH to set credentials Ssh key to access ....com > git fetch --tags --progress ssh://...:2222/~dmitry.korotkov/sampleprojectsforjenkins.git +refs/heads/*:refs/remotes/origin/* # timeout=10 Polling for changes in Seen branch in repository origin/dmitrykorotkov/Jenkinsfile-1595400745873 Seen branch in repository origin/master Seen 2 remote branches > git show-ref --tags -d # timeout=10 Done. Took 0.37 sec No changes
At that time there are two more commits in repository in master branch:
Looks like there is some cache which becomes blocked/broken when settings change or something like that.
Please let me know if you need any additional information (job's config files, logs, whatever else).
This seems like an ideal case to use a multibranch pipeline so that Jenkins will manage the creation and deletion of jobs automatically rather than having a single job that switches between branches.
A single job that switches between branches will not show useful information in the "Changes", since it cannot compute what changed from one branch build to a different branch build.
This seems like a valid bug report, but it is not a bug report that I intend to address. The multibranch pipeline feature in Jenkins is so powerful that I'd rather invest improvement efforts on that area than place effort trying to adapt to a single pipeline job or a single freestyle job that switches between branches.