Herald rule on creating audit

I’d like to add a herald rule which is fired when an audit is created and another when it is closed. In my workflow this fires a webhook to push some data to Jira.

Is this possible in any way?

You can not use Herald to select these state change events.

Instead, use Herald to fire a webhook on a superset of the events you care about (for example, fire on every audit), then have your webhook exit without taking action if none of the transactions are things you care about.

How would I get Herald to fire on every audit? When I create a new Herald rule, there is no option for “audit”. I can fire on commit, diff, and much more but audit or diffusion isn’t in the list.

Create a rule for “Commits”, something like this:

There must be something more fundamental I’m missing here, since I want to fire the webhook when an audit is created, not on every commit. Sometimes we create audits automatically on commit, but only for some files.

Mostly we create audits manually by ‘raising a concern’ on a commit. So the audit is created sometime after the commit, or not at all.

Perhaps I’m using the wrong terminology for what I’m trying to describe here.

Or are you saying that we need to capture an “update” event on a commit and then handle that in the webhook? And ‘raising a concern’ fires this sort of update event?

You create a rule to fire a webhook on every commit event.

This includes commit creation, auditor changes, accepts, comments, subscribes, token awards, and so on – everything. Any time a user or another application interacts with a commit, you’ll be notified of the change.

Your script which receives the webhook notification will receive a list of transaction PHIDs describing what changed. It can call transaction.search to get details about exactly what happened.

If it sees that nothing you care about happened (for example, a user added a comment or awarded a token, or a new commit was discovered but no audits triggered), it can just exit without taking any action.

If it sees that something interesting happened (auditors were added, concern was raised, a commit was accepted, etc), you can take some sort of action in response.

Auditors may be added when a commit is created (by Herald, Owners, or “Auditors: …” in commit messages) so, in the general case, you need to receive events at every phase of the commit lifecycle to react to all audit changes.

Note that transaction.search may not return details for every transaction you’re interested in; I don’t remember offhand if we’ve enriched audit transactions yet or not. If some transactions aren’t coming back with all the data you need, we can likely flesh them out.

That’s really helpful, thanks for that.