Determine if job was scheduled or ran manually

Why don't you set the dropdown variable's default to be the value to force the build, and set up the scheduled job so that the dropdown variable's value is to skip the build if there are no new change sets?

Why don't you set the dropdown variable's default to be the value to force the build, and set up the scheduled job so that the dropdown variable's value is to skip the build if there are no new change sets?

Pardon my lack of skill, but how do I override a variable for schedules? I guess I could try chaining to environments together... better way?

How can I determine in a linked adaptor whether a job was manually ran or automatically scheduled?

One idea was to use a dropdown variable and have the default set to make it so that automatic runs would be set to one value, while the user could optionally select a different value for manual runs. This is a bit cumbersome because the user has to remember to select this option, but it's still a possible work around.

The reason I want to know whether a job was manually ran or scheduled is because my continuous integration adaptor link should not cancel a job if the job was manually requested in the event that there were no new change sets found. However, if it is a scheduled continuous integration run, than a job with no new changes should be skipped.

You might be able to experiment with a couple these things:

- The 'BF_USER' built-in variable represents the job owner. If you were to set up a schedule with a special user that would never manually start a build, then that could be something to differentiate the two types of builds.

- When using an environment with a schedule, the environment is actually copied to the schedule. The 'Resync Environment' button on the schedule page allows you a way to get the two back to the same should the original environment be modified. However, in this case the difference between the two could be used to your advantage. If you were to set a variable in the environment, then set on the schedule, then go back to the environment and remove or alter the value - then you would have something to differentiate the two. Of course, you would need to make sure that nobody clicks the 'Resync Environment' button on the schedule or alters the original environment.

Brent Ulbricht
RTC Build Lead

When we create schedules, we use the project's default environment, but don't check the 'Resync Environment' option. This allows us to override the default values. Typically we only schedule it for a "Once Only", and reuse the schedule later. I've noticed that with this usage, if someone updates text fields in the environment and saves it, the schedule will pick that up, but not changes in the pulldown variables.