jenkinsci / jenkinsci/git-plugin

[JENKINS-61845] Poll SCM enqueue a build when a build for the same commit is already running

Open
#3,541 4 comments 0 reactions 0 assignees View on GitHub
component:git-plugin imported-jira-issue priority:minor resolution:unresolved
Dominant language
Java
Stars
694
Forks
1.1k
Avg merge
1h 29m
Merged PRs (30d)
3

Description

We have a job with "Poll SCM" running on `* * * * *` (every minute). We need to use "Included Regions" so the local polling strategy is used. The build takes about 30 minutes. It correctly ignores changes in the steady state but when a commit comes in, it correctly notices a change saying something like:

[poll] Last Built Revision: Revision 50fc7882752856ac86b0838fdf878897e17955cd (refs/remotes/origin/master)

Done. Took 6 ms
Changes found

and starts the build. But then 1 minute later, it notices the same thing and starts another build. These new builds continue to be started until one of them finishes and then the queueing stops.

I've tried all sorts of combinations to try and get new jobs to not start with the exact same SHA but to no avail. The closest I can get is to let only 1 concurrent build go at a time, but that still leaves 1 job in the queue and we end up double building everything.

Is there a way to have the SCM polling take into account existing builds?

---
Originally reported by ptarjan, imported from: Poll SCM enqueue a build when a build for the same commit is already running


  • status: Open
  • priority: Minor
  • component(s): git-plugin
  • resolution: Unresolved
  • votes: 0
  • watchers: 3
  • imported: 2025-12-02

Raw content of original issue

We have a job with "Poll SCM" running on `* * * * *` (every minute). We need to use "Included Regions" so the local polling strategy is used. The build takes about 30 minutes. It correctly ignores changes in the steady state but when a commit comes in, it correctly notices a change saying something like:



[poll] Last Built Revision: Revision 50fc7882752856ac86b0838fdf878897e17955cd (refs/remotes/origin/master)

Done. Took 6 ms
Changes found


and starts the build. But then 1 minute later, it notices the same thing and starts another build. These new builds continue to be started until one of them finishes and then the queueing stops.

I've tried all sorts of combinations to try and get new jobs to not start with the exact same SHA but to no avail. The closest I can get is to let only 1 concurrent build go at a time, but that still leaves 1 job in the queue and we end up double building everything.

Is there a way to have the SCM polling take into account existing builds?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.