[JENKINS-72089] way to detect scheduled vs live builds

[jenkins-infra-bot]

I have a use case where unattended builds need some different error handling than builds which someone is watching. Can we add something to the cause, or some other way of detecting if the build was started with "schedule build" vs "build now"?

---

Originally reported by ckiick_sp, imported from: way to detect scheduled vs live builds

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

Raw content of original issue

I have a use case where unattended builds need some different error handling than builds which someone is watching. Can we add something to the cause, or some other way of detecting if the build was started with "schedule build" vs "build now"?

environment

Jenkins 2.387.1<br/>
Schedule Build Plugin Version 448.vb_1dccb_0961b_d

[jenkins-infra-bot]

• Remote link associated with this issue:

  • PR-448

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  You could add a parameter to the build with a default value, then set a non-default value when scheduling as a user.
  
  I don't plan to add additional build cause information for builds that are started by the schedule build plugin.
  

You could add a parameter to the build with a default value, then set a non-default value when scheduling as a user.

I don't plan to add additional build cause information for builds that are started by the schedule build plugin.

[jenkins-infra-bot]

mawinter69:

• Original comment link
• Raw content of original comment:

  technically impossible with the current way core and the plugin work. When you use the Build Now button you basically do a post request to this url (or visit this url when the job has parameters)
  
  <joburl>/build?delay=0sec
  
  The plugin is just adding some logic in front so the delay parameter is changed. This btw has the effect that when you schedule a job with parameters you will never get that exact timestamp you entered because the delay applies to the time when pressing the build button on the parameters page. So the run will actually start a few seconds to several minutes later depending how long you need to enter all parameters.
  

technically impossible with the current way core and the plugin work. When you use the Build Now button you basically do a post request to this url (or visit this url when the job has parameters)

/build?delay=0sec

The plugin is just adding some logic in front so the delay parameter is changed. This btw has the effect that when you schedule a job with parameters you will never get that exact timestamp you entered because the delay applies to the time when pressing the build button on the parameters page. So the run will actually start a few seconds to several minutes later depending how long you need to enter all parameters.