Publish event when Dependabot jobs finish so users can trigger a GitHub Actions workflow

[mwaddell]

There are currently many open issues that could be solved more generally by allowing chaining between dependabot and other workflows. You can currently trigger dependabot from a custom workflow by its reopening a closed PR, adding new @dependabot comments to a PR, or issuing POST requests to /{owner}/{repo}/network/updates?update_config_id={update_config_id}.

However, triggering a custom workflow from dependabot is significantly more limited. You can currently only trigger a custom workflow from dependabot if it creates a new PR during that run (e.g. enable-auto-merge). There is no way to trigger a custom workflow if the run fails or if it completes successfully but without creating at least one PR.

At the end of each run, the final entry in the log file is in the form:

updater | time="{ts}" level=info msg="task complete" container_id={id} exit_code=0 job_id={update-config-id}

or

updater | time="{ts}" level=warning msg="failed during fetch, skipping updater" job_id={update-config-id}

I propose that whenever this line is written it also triggers a dispatch event for an optional custom workflow. This would be supported using a new option be added to the dependabot configuration called trigger-workflow-id defined as follows:

trigger-workflow-id

Use trigger-workflow-id to specify the id of a workflow that dependabot will create a workflow dispatch event for upon the completion of each run. This event will be created as a POST request to /repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches with the following body:

{
  "ref": "{target-branch}",
  "inputs": {
    "msg": "{msg}", 
    "exit_code": {exit_code},
    "job_id": "{update-config-id}"   
  }
}

This very basic implementation would provide the ability to trigger custom actions (push notifications, etc) if an error occurred. It would also allow for workflows to use github-script in the triggered workflow to identify all of the pull requests that were created, updated or closed by that most recent run in order to perform custom actions on them. A more sophisticated custom action could pull the full log (using the update-config-id) and parse it to enumerate ignored dependencies, etc.

I looked through the source code for this repo and I don't see where that final line in the log file is generated, so I'm not sure how someone from the community could provide a PR to resolve this issue. However, if there is some other repo that contains that code, please point me in that direction. Since it doesn't seem to be part of dependabot_core, the new trigger-workflow-id might have to be at the top-level instead of allowing one for each update entry, but that would be fine for the purpose of this task.

[jeffwidman]

This is a great idea, and I've raised it internally. No promises.

But it would unlock a lot of custom use cases / features that people are wanting that are too niche for us to build out for everyone.