Enable webhooks for JobResults

[kkthxbye-code]

NetBox version

v3.1.9

Feature type

Change to existing functionality

Proposed functionality

Add the @extra_features('webhooks') to the JobResult model.

Use case

When triggering Netbox scripts via. the API it would be useful to be able to send a webhook when the status changes. This would prevent the need for polling the API for scripts with longer runtime.

Database changes

None

External dependencies

No response

[kkthxbye-code]

I tried just adding @extras_features('webhooks') to the model, but it doesn't trigger webhooks. I'm sure there are some pre-requisites for using webhooks I'm not aware of. I wouldn't mind implementing if accepted and with a small pointer as to what is needed to make it work.

[kkthxbye-code]

Looking into this more, I guess JobResults would be to be changed to inherit from ChangeLoggedModel. Not sure how feasible that is or if it just works out of the box. The migration would make it a significant change I guess.

[jeremystretch]

I guess JobResults would be to be changed to inherit from ChangeLoggedModel

We can enable webhooks for the model separately, without having to inherit the other stuff ChangeLoggedModel provides.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

[github-actions]

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

[jeremystretch]

@kkthxbye-code would we want to evaluate webhook on every call to save(), or only for jobs with a terminal status (e.g. completed or errored)? The former would provide the most flexibility, though I worry about people creating non-conditional webhooks that fire each time a job is created, executed, and completed.

[kkthxbye-code]

@jeremystretch - The original issue we were having, was that we had to poll to check for script completion when triggering scripts from external systems. So only triggering for terminal statuses would probably be fine for that use-case. However I don't think it should be an issue doing it on all saves, unless JobResults are saved multiple times during execution? A normal script run would be Pending -> Running -> Completed right?

[jeremystretch]

Right, what I mean is that each change to a job's status has to be written to the database (although it might not actually call save()), which could in theory trigger a webhook each time.

[jeremystretch]

I suppose for the initial implementation at least we can enable webhooks for all statuses, and then constrain to only terminal statuses if needed.

[jeremystretch]

I ended up introducing two new event types, job_start and job_end, which trigger at the beginning and end of a job's execution respectively. These map to the start() and (new) terminate() methods on the JobResult class, which handle triggering webhooks in addition to updating the job's status.