Here's a first pass at solving this. I have the approach that most additions should be plugins. When I looked at the Trigger extension point I was sceptical that this should be a plugin. The CronTab and CronTabList classes did not want to cooperate.

Then there is the is the configuration. In order to make the parameterized schedule enabled only for projects with parameters I seem to have forced the user to re-enter the config screen after setting parameters. This does not flow well.

Now that I've implemented it as a plugin, I suspect it should be in core. Else the Trigger extension point needs some refactoring to support different kinds of triggers. It's my opinion that the Trigger was nearly already in need of refactoring. This is evidenced by Trigger.getSpec(), checkTriggers is static but other Trigger implementations may not be the least bit interested in CronTabList. For my part, I needed to extend CronTab to support parameters stored with each.

I'm interested to hear the opinion of others closer to, with more experience in, the jenkins-core.

https://github.com/jwmach1/parameterized-scheduler

Wouldn't it be better to have this logic in the build script?

Even if this were added, it's very likely the next person wants to run arbitrary scripts because the rules he needs to implement are more complicated.

If I can still schedule a build that has non-default build parameters, cool. The use case I have is with around a dozen projects, each needs to build with different parameters (one of the parameters is for what environment to test against) for different times of the day/week. Creating a non-parameterized build for each project, for each of the different parameter combinations is an administrative nightmare

The use case I have is with around a dozen projects, each needs to build with different parameters (one of the parameters is for what environment to test against) for different times of the day/week.

What I mean is, don't make these parameters that only depend on date/time in Jenkins. Let the job be parameterless (or at least without these parameters), and determine day of week in the build script and adapt behavior there.

We are using Jenkins as an orchestration engine to kick off tasks. We have a common task shared across multiple teams that just varies by parameters. For scheduling, this would be really nice for us to be able to let our users schedule their task with the parameters for their tests and have it kick off when they want at a set time.

danielbeck just found this issue and the plugin above.

> Let the job be parameterless (or at least without these parameters), and determine day of week in the build script and adapt behavior there.

Actually, for the use case that led me here, that wouldn't seem doable: in our situation, people who are going to specify those values aren't developers/very technical. It's far easier to ask them to specify cron + param=value form than to twiddle with shell-scripting. So I'd personnally like to consider this plugin get forked.