I'm unable to duplicate the problem, even with your config.xml file.
I compared the config.xml you uploaded with the config.xml of my test job. The differences included:
- Your config.xml polls every minute. Mine is configured with polling but with no schedule so that the job will respond to notifyCommit without wasting the effort polling
- Your config.xml file is XML 1.0, mine is 1.1. That difference should be irrelevant
- Your config.xml references /path/to/my/repository.git. My config.xml references my bug check repository. I'm using a network based git server and I assume you are also using a network based git server. If instead you are using file system access to a repository on your Jenkins server, you might try using a network protocol to access the git repository rather than file system access. I rarely test direct file system access to git repositories because it would limit jobs to only run on the master
Based on the differences between my config.xml and yours, I configured my job to poll every minute. I committed a change to the repository, waited one minute, and confirmed that the change was detected and the job ran. I committed two changes to the repository, waited for the next polling, and confirmed that the changes were detected and the job ran. I committed three changes to the repository, waited for the next poll, and confirmed the changes were detected.
I also confirmed that if I use a notifyCommit hook in the central git repository to alert the Jenkins server that it should poll, the changes are detected as soon as they are applied, without the overhead of polling once a minute. My central git repository is a small computer hosting ssh based git repositories. In the hooks directory of that repository, I have an executable script named post-receive like this:
curl -s http://mark-pc2.markwaite.net/git/notifyCommit?url=https://github.com/MarkEWaite/jenkins-bugs
That script is automatically executed by git each time a commit arrives at that repository. That script is an example of the concept that Kohsuke Kawaguchi described in his blog post, "polling must die". It may be worth experimenting with notifyCommit to avoid the overhead of polling and the delay of polling.
Alternately, if you're using a git hosting system like GitHub, Bitbucket, GitLab, or Gitea, they offer web hooks which can do the same thing. The web hooks are often managed by Jenkins plugins focused on the specific provider.
There is another possible difference between the job you're running and the job that I'm running. My Jenkinsfile is probably different from yours. I would hope that whatever differences there are between those two files, they would be irrelevant to this case. However, you might experiment with a variant of my Jenkinsfile in your environment, just to see if the contents of my Jenkinsfile make polling work, while yours does not.