Job Schedule - parameters
I have a job schedule which runs every 6 hours, 4 times a day starting at 00:00.
I need to implement the usage of a static analysis tool into the build process which slightly changes the way the build is invoked and performs a couple of other actions post-build. Using the tool takes a considerable amount of time, so the idea is to only run it for the 00:00 build.
I need a way to know at build time that this is the 00:00 build and based on that to slightly change what we do at build time, so first thought was to see if I can pass a parameter from the scheduler only for the 00:00 build, but that does not seem possible.
Aside from breaking this schedule into two schedules, one build for 00:00 and three builds for the 2nd schedule, any thoughts of how I can have a parameter passed into the build procedure? I also thought of getting the job start time since the biggest delay on a schedule I can see is about 11 seconds, but it creates a dependency between the build procedure and the specific time at which we run such that if anybody changes the schedule time we'll need to remember to also change the code accordingly, which will likely not happen until we hear back from unhappy developers.
Best Answer
Guys, thank you so much for your help, I really appreciate it. I thought some more about it and came up with an idea. We already have some scripts (ec-perl) who allow us to find jobs older than a number of days, and then we further use those jobs to delete the associated workspaces and posts (runtime uploads). I think that I can use that as a baseline, and do something like
- find all of the jobs newer than 2 days (although I will test 1 day to see what I get) that belong to 'this' project and procedure
- filter by 'completed' and 'successful'
- get the start date and extract the day
- calculate current day
If there's a match between the job day and today (successful/completed/today), then skip, else build for static analysis.
Hope that will work, will give it a shot.
One approach:
Have your script always store the "last run date" in a procedure-level property. Then compare the current date to the last date, and if they are different, then you know you want to run the extra steps. This way if your server was ever down for a time frame (re: upgrade) then the 1st run of the day would still end up generating the extra data.
Based on the other three answers, this seems to fit the best.
Your run condition for static code analysis should depend on a variable, and maybe set that variable when it runs.
Unsetting the variable can probably be handled in a separate job.
I'm sure with enough variable kung-fu it can be done all within the static code analysis step.
I'm not sure exactly how you want to set this up, but if you want to run the static analysis tool on the first job in the day (out of the four times it runs), you might use getSchedule to get the startTime and then compare that with the actual job's createTime (or start). That way, the particular time isn't hard-coded, but depends on the schedule.
The difficulty here is that the schedule's startTime is associated with a time zone, and the job's createTime and start are in UTC, so you'd need to handle the conversion. This isn't an insurmountable problem, but is a bit of a pain. Come back if you need some help with the conversion. (Time conversions are the kinds of things that I puzzle out painstakingly, then save up for use in later code, so I may have something suitable.)
What about using a new parameter name Start that you would fill automatically with some code like:
$[/timestamp HH]
Then in you code you could check
if ($[Start] < 4)
That way if the start is delayed you can still catch it.
