[JENKINS-59612] Scheduled build is removed if job is run earlier with same parameters

[jenkins-infra-bot]

We have a deployment job that has a VERSION parameter, which can be a branch name.

 

Example:
Schedule a job for tomorrow with VERSION=develop.

Schedule a job for next week with VERSION=master.

 

Scenario 1)

Directly deploy with VERSION=feature/new-buttons

Outcome: The two scheduled jobs still exist.

 

Scenario 2)

Directly deploy with VERSION=master

Outcome: The scheduled job with VERSION=master doesn't exist anymore.

 

The outcome in scenario 2 may seem logical. But on the other hand, it's not. If I plan a deployment for next week, I should not have impact when I deploy something right now.

 

The use case is:

Schedule a certain branch to deploy next week, while in the mean time patches in that branch can be deployed.

---

Originally reported by pietervogelaar, imported from: Scheduled build is removed if job is run earlier with same parameters

• assignee: mawinter69
• status: In Progress
• priority: Minor
• component(s): schedule-build-plugin
• resolution: Unresolved
• votes: 1
• watchers: 3
• imported: 20260512-210953

Raw content of original issue

We have a deployment job that has a VERSION parameter, which can be a branch name.

 

Example:
Schedule a job for tomorrow with VERSION=develop.

Schedule a job for next week with VERSION=master.

 

Scenario 1)

Directly deploy with VERSION=feature/new-buttons

Outcome: The two scheduled jobs still exist.

 

Scenario 2)

Directly deploy with VERSION=master

Outcome: The scheduled job with VERSION=master doesn't exist anymore.

 

The outcome in scenario 2 may seem logical. But on the other hand, it's not. If I plan a deployment for next week, I should not have impact when I deploy something right now.

 

The use case is:

Schedule a certain branch to deploy next week, while in the mean time patches in that branch can be deployed.

[jenkins-infra-bot]

• Remote link associated with this issue:

  • PR-448

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  This is a limitation of Jenkins core that actively works to prevent duplicate adjacent builds that have the same parameters.  One technique to work around the issue is to use a parameter in the job that is assigned a unique value on each run.  That could be a random value or use some other technique to make it different.
  

This is a limitation of Jenkins core that actively works to prevent duplicate adjacent builds that have the same parameters. One technique to work around the issue is to use a parameter in the job that is assigned a unique value on each run. That could be a random value or use some other technique to make it different.