Just tested 2.46.2 in Docker container, could not reproduce the bug but I won't claim it is actually fixed.
- Add a hello world git repo
- Set polling to * * * * *
- Build command: /bin/sleep 130
This makes the build step overextend the polling schedule. Un?-fortunately I did not get a second build on scm change.
Latest remote head revision on refs/heads/master is: 57b85c7d801eae284d8b1ab9f6fcd1fb3390a15f - already built by 3
This is in the logs while build 3 is still going.
I also did some light digging through the code and it seems that when a build is started it is immediately saved with the sha1 revision so I was unable to determine any real flaws in the logic. I was unable to determine how and when build is saved to persistent storage though and I don't know if Jenkins uses some kind of cache. But the code does check if revision has been built already and opening the ongoing build does list the correct sha1 revision.
The only thing that bothered me is that code and comments refer to builds as if they are "in the past" and already finished, I didn't find any differentiation between finished builds and ongoing builds.
Perhaps if we manage to come up with a simple reproducible scenario someone from Jenkins team can take a look at this, I suspect it is an easy fix once reproduced and narrowed down.
Can you duplicate the problem with another job? with another repository? with another Jenkins server?
Can you provide steps to configure the job which shows how to duplicate the problem?