Interactive Jobs
Last updated
Last updated
Sometimes you have a task that will run for a while or just produce a lot of logging output as it executes to let the user know what's going on. it is very easy to keep the user up to date with the print helper like so:
This can create a lot of output however which can look a little messy. Plus if you have a task that runs another task or command, all the output from each steps gets mixed together. This is where Interactive Jobs help you harness the power of redrawing the console over and over to nicely format what steps have completed and have logging for each step that goes away once the step is complete.
Interactive Jobs are best if you have a small enough number of jobs that they can all fit on one screen. Since the output of the jobs is updated in real time, it doesn't scroll past the bottom of the terminal and CommandBox will just truncate any extra text.
We have a nice DSL you can call that signals the start and end of each job. Every job has a name, zero or more log messages, and a final status of whether it was successful. The
variable is automatically available for custom commands and Task Runners.job
The log messages will show up in the order they appear, but once you complete the job, the log messages are hidden and only a single, green line shows to represented the completed job regardless of how many steps it had in the meantime. Do not output normal text with the print
helper if possible. Once you've started the job, use the job.addLog()
calls.
The final output of the above code would be this green text:
You can log the individual steps of your job for instant user feedback:
Feel free to add ANSI formatting to your log messages, but we have some convenience method for you already.
By default, a job will only show the last 5 log lines to keep things tidy. Configure this when you start the job.
All good things must come to an end. use the complete()
method to show that your job has finished successfully. use the error()
method to show your job has ended but with issues.
The job.error()
method can take an optional message to describe what happened which will remain on the screen. If a Task Runner has an unhandled error or the user interrupts execution with Ctrl-C, CommandBox will end the job for you as an error. The exception message will be passed to the job.error()
call for you so the user can see what happened.
If you want to have a verbose mode in your task that dumps out all the log messages at the end you can do that by passing dumpLog
as true in your job.complete()
or job.error()
calls. This is great for debugging tasks that ran on a CI server. This dumps ALL logging lines regardless of what your logSize
was set to. logSize
is only used for the interactive output during execution to keep things clean.
Ok, so here is where it really gets cool. Let's say you have a Task Runner that starts a server, which in turn installs a new Adobe CF engine. That's 3 jobs all nested inside of each other. You can call job.start() at any time, and the Interactive Job handler will keep a call stack of what's going on. Log messages always get added to the last job to be started. (Last In, First Out)
The output of this is:
Here we have two nested jobs. The first two lines would be red representing the outer failed job and it's failure message. The 3rd indented line would be green representing the nested job that completed successfully.
And if we add dumpLog
to each job, what do we get?
Interactive jobs are fully compatible with progressable downloaders as well as the multi-select input control. Any progress bars will display at the bottom of the job output and disappear when complete.
If for some reason you need to call an external process that outputs text that you can't control and funnel through a job or you need to stop and ask the user a question with the ask()
function, you can temporarily clear out output from all current jobs.
All the output will come back the next time you call a job method.
Check if there is currently a job running like so:
If there are several nested jobs currently running and something catastrophic happens and you just want to mark all the in progress ones as errors without necessarily knowing how many are still currently running you can do this:
This can be handy to call from some high level error handling that can catch errors from tasks/commands/functions several layers deep. It's basically your escape hatch.