|
without looking at the code, I'm leaning towards ... 3. Move the code that "checks" somewhere it can be shared between (1) and (2) As written, Sorry, but I think I have not explained: if ( isScheduleFromBuildJob( schedule ) )
{
// A buildDefinition with this schedule
schedule( schedule, continuum, ContinuumBuildJob.class );
}
if ( isScheduleFromPurgeJob( schedule ) )
{
// A purge with this schedule
schedule( schedule, continuum, ContinuumPurgeJob.class );
}
That way if the schedule is not linked to a buildDefinition or purgeConfiguration not work for them. After set a schedule for a buildDefinition/purgeConfiguration we need to update the schedule to add job(s) to application scheduler. In this way, my options are: I think i'll go with [2]. After setting a schedule on a purgeConfiguration or buildDefinition, we add another call to schedule the job. Same goes when unsetting a schedule on purgeConfiguration/buildDefinition, scheduled job should be removed. Fixed in : r780709 of branch 1.3.x |
|||||||||||||||||||||||||||||||||||||||||||
Actually Continuum add a schedule is associated with a buildDefinition or purge process. Then you need an enable disable previously if it was not associated with a project. I think there are two possible solutions:
1.- When whe updated or add a new build definition or purge process we would check if associated schedule jobs is in queuue (pending to execute) and enable/disable it.
2.- Always (active = true) enqueue 2 jobs, first for buildProcess and second for purge process. They check if there are associated elements to execute process.
What solution do you think is better?