You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -47,7 +48,7 @@ The location of the `node` binary may vary on your servers.
47
48
48
49
As soon as your Plugin is launched as a sub-process, a JSON document is piped to its STDIN stream, describing the job. This will be compacted onto a single line followed by an EOL, so you can simply read a line, and not have to worry about locating the start and end of the JSON. Here is an example JSON document (pretty-printed here for display purposes):
49
50
50
-
```js
51
+
```json
51
52
{
52
53
"id": "jihuxvagi01",
53
54
"hostname": "joeretina.local",
@@ -84,13 +85,13 @@ The `params` object will contain all the custom parameter keys defined when you
84
85
85
86
Your Plugin is expected to write JSON to STDOUT in order to report status back to the Cronicle daemon. At the very least, you need to notify Cronicle that the job was completed, and the result of the job (i.e. success or fail). This is done by printing a JSON object with a `complete` property set to `1`, and a `code` property set to `0` indicating success. You need to make sure the JSON is compacted onto a single line, and ends with a single EOL character (`\n` on Unix). Example:
86
87
87
-
```js
88
+
```json
88
89
{ "complete": 1, "code": 0 }
89
90
```
90
91
91
92
This tells Cronicle that the job was completed successfully, and your process is about to exit. However, if the job failed and you need to report an error, you need to set the `code` property set to any non-zero error code you want, and add a `description` property set to a custom error string. Include these along with the `complete` property in the JSON. Example:
92
93
93
-
```js
94
+
```json
94
95
{ "complete": 1, "code": 999, "description": "Failed to connect to database." }
95
96
```
96
97
@@ -104,7 +105,7 @@ Please note that the once you send a JSON line containing the `complete` flag, C
104
105
105
106
In addition to reporting success or failure at the end of a job, you can also optionally report progress at custom intervals while your job is running. This is how Cronicle can display its visual progress meter in the UI, as well as calculate the estimated time remaining. To update the progress of a job, simply print a JSON document with a `progress` property, set to a number between `0.0` and `1.0`. Example:
106
107
107
-
```js
108
+
```json
108
109
{ "progress": 0.5 }
109
110
```
110
111
@@ -114,23 +115,23 @@ This would show progress at 50% completion, and automatically calculate the esti
114
115
115
116
You can optionally include performance metrics at the end of a job, which are displayed as a pie chart on the [Job Details Tab](WebUI.md#job-details-tab). These metrics can consist of any categories you like, and the JSON format is a simple `perf` object where the values represent the amount of time spent in seconds. Example:
The perf keys can be anything you want. They are just arbitrary categories you can make up, which represent how your Plugin spent its time during the job.
122
123
123
124
Cronicle accepts a number of different formats for the perf metrics, to accommodate various performance tracking libraries. For example, you can provide the metrics in query string format, like this:
124
125
125
-
```js
126
+
```json
126
127
{ "perf": "db=18.51&http=3.22&gzip=0.84" }
127
128
```
128
129
129
130
If your metrics include a `total` (or `t`) in addition to other metrics, this is assumed to represent the total time, and will automatically be excluded from the pie chart (but included in the performance history graph).
130
131
131
132
If you track metrics in units other than seconds, you can provide the `scale`. For example, if your metrics are all in milliseconds, just set the `scale` property to `1000`. Example:
@@ -140,15 +141,15 @@ The slightly more complex format produced by our own [pixl-perf](https://www.npm
140
141
141
142
In order for the pie chart to be accurate, your perf metrics must not overlap each other. Each metric should represent a separate period of time. Put another way, if all the metrics were added together, they should equal the total time. To illustrate this point, consider the following "bad" example:
In this case the Plugin is tracking three different metrics, but the `database` metric encompasses *all* database related activities, including the `run_sql_query` and `connect_to_db`. So the `database` metric overlaps the others. Cronicle has no way of knowing this, so the pie chart would be quite inaccurate, because the three metrics do not add up to the total time.
148
149
149
150
However, if you want to track nested metrics as well as a parent metric, just make sure you prefix your perf keys properly. In the above example, all you would need to do is rename the keys like this:
@@ -162,25 +163,25 @@ Notification settings for the job are configured in the UI at the event level, a
162
163
163
164
For example, if you only want to send a successful e-mail in certain cases, and want to disable it based on some outcome from inside the Plugin, just print some JSON to STDOUT like this:
164
165
165
-
```js
166
+
```json
166
167
{ "notify_success": "" }
167
168
```
168
169
169
170
This will disable the e-mail that is normally sent upon success. Similarly, if you want to disable the failure e-mail, print this to STDOUT:
170
171
171
-
```js
172
+
```json
172
173
{ "notify_fail": "" }
173
174
```
174
175
175
176
Another potential use of this feature is to change who gets e-mailed, based on a decision made inside your Plugin. For example, you may have multiple error severity levels, and want to e-mail a different set of people for the really severe ones. To do that, just specify a new set of e-mail addresses in the `notify_fail` property:
These JSON updates can be sent as standalone records as shown here, at any time during your job run, or you can batch everything together at the very end:
@@ -190,21 +191,21 @@ You can enable or disable [Chain Reaction](WebUI.md#chain-reaction) mode on the
190
191
191
192
To enable a chain reaction, you need to know the Event ID of the event you want to trigger. You can determine this by editing the event in the UI and copy the Event ID from the top of the form, just above the title. Then you can specify the ID in your jobs by printing some JSON to STDOUT like this:
192
193
193
-
```js
194
+
```json
194
195
{ "chain": "e29bf12db" }
195
196
```
196
197
197
198
Remember that your job must complete successfully in order to trigger the chain reaction, and fire off the next event. However, if you want to run a event only on job failure, set the `chain_error` property instead:
198
199
199
-
```js
200
+
```json
200
201
{ "chain_error": "e29bf12db" }
201
202
```
202
203
203
204
You set both the `chain` and `chain_error` properties, to run different events on success / failure.
204
205
205
206
To disable chain reaction mode, set the `chain` and `chain_error` properties to false or empty strings:
206
207
207
-
```js
208
+
```json
208
209
{ "chain": "", "chain_error": "" }
209
210
```
210
211
@@ -221,7 +222,7 @@ When a chained event runs, some additional information is included in the initia
221
222
222
223
You can pass custom JSON data to the next event in the chain, when using a [Chain Reaction](WebUI.md#chain-reaction) event. Simply specify a JSON property called `chain_data` in your JSON output, and pass in anything you want (can be a complex object / array tree), and the next event will receive it. Example:
@@ -231,7 +232,7 @@ So in this case when the event `e29bf12db` runs, it will be passed your `chain_d
231
232
232
233
In addition to passing `chain_data` to chained events (see above), you can also override some or all the *parameters* of the chained event (the key/value pairs normally populated by the Plugin). To do this, specify a JSON property called `chain_params` in your JSON output, and pass in an object containing param keys. This will be merged with the default event Plugin parameters when the chained job is executed. Example:
@@ -250,7 +251,7 @@ If your Plugin produces statistics or other tabular data at the end of a run, yo
250
251
251
252
Here is an example data table. Note that this has been expanded for documentation purposes, but in practice your JSON needs to be compacted onto a single line when printed to STDOUT.
252
253
253
-
```js
254
+
```json
254
255
{
255
256
"table": {
256
257
"title": "Sample Job Stats",
@@ -290,12 +291,12 @@ If you would prefer to generate your own HTML content from your Plugin code, and
290
291
291
292
Here is an example HTML report. Note that this has been expanded for documentation purposes, but in practice your JSON needs to be compacted onto a single line when printed to STDOUT.
292
293
293
-
```js
294
+
```json
294
295
{
295
296
"html": {
296
-
title:"Sample Job Report",
297
-
content:"This is <b>HTML</b> so you can use <i>styling</i> and such.",
298
-
caption:"This is a caption displayed under your HTML content."
297
+
"title": "Sample Job Report",
298
+
"content": "This is <b>HTML</b> so you can use <i>styling</i> and such.",
299
+
"caption": "This is a caption displayed under your HTML content."
299
300
}
300
301
}
301
302
```
@@ -308,15 +309,31 @@ Your job can optionally trigger an event update when it completes. This can be
308
309
309
310
To update the event for a job, simply include an `update_event` object in your Plugin's JSON output, containing any properties from the [Event Data Format](APIReference.md#event-data-format). Example:
310
311
311
-
```js
312
+
```json
312
313
{
313
314
"update_event": {
314
315
"enabled": 0
315
316
}
316
317
}
317
318
```
318
319
319
-
This would cause the event to be disabled, so the schedule would no longer launch it. Note that you can only update the event once, and it happens at the completion of your job.
320
+
This would cause the event to be disabled, so the schedule would no longer launch it. Note that you can only update the event once, and it happens at the completion of your job. Remember, the JSON must be compacted on one line like this:
321
+
322
+
```json
323
+
{ "update_event": { "enabled": 0 } }
324
+
```
325
+
326
+
#### Custom Job Labels
327
+
328
+
Your can optionally add custom labels to your jobs, which will be displayed on the completed job history pages alongside the Job IDs. This is useful if you launch jobs with custom parameters, and need to differentiate them in the completed list.
329
+
330
+
To set the label for a job, simply include a `label` property in your Plugin's JSON output, set to any string you want. Example:
331
+
332
+
```json
333
+
{ "label": "Reindex Database" }
334
+
```
335
+
336
+
This would cause the "Reindex Database" label to be displayed alongside the Job ID.
0 commit comments