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.

[nmiddendorff]

Hey @mwaddell, I'm curious if your approach to POST /{owner}/{repo}/network/updates works. When hitting that endpoint in CI using https://api.github.com I get a 404. Similarly, I get Cookies must be enabled to use GitHub. when hitting https://github.com

[mwaddell]

No, unfortunately not in quite a while. The URL that I was using was part of the web API and so it required a valid session cookie which now is no longer sufficient because of CSRF mitigation measures that were added. I don't believe that a similar end point was ever added to the API that is accessible programmatically.

[0xdevalias]

Just saw this announcement blog today, which sounds like it might provide another way to achieve these things:

• https://github.blog/2024-05-02-dependabot-on-github-actions-and-self-hosted-runners-is-now-generally-available/

  • Starting today, administrators using Github.com accounts can enable their repositories and/or organizations to run Dependabot updates jobs as a GitHub Actions workflow using both hosted and self-hosted runners. Running Dependabot does not count towards GitHub Actions minutes–meaning that using Dependabot continues to be free for everyone.

• https://docs.github.com/en/code-security/dependabot/working-with-dependabot/about-dependabot-on-github-actions-runners#about-dependabot-on-github-actions-runners

  • About Dependabot on GitHub Actions runners

  • Using GitHub Actions runners allows you to more easily identify Dependabot job errors and manually detect and troubleshoot failed runs. You can also integrate Dependabot into your CI/CD pipelines by using GitHub Actions APIs and webhooks to detect Dependabot job status such as failed runs, and perform downstream processing.

[nmiddendorff]

@0xdevalias, we are actually using Dependabot on self-hosted runners already. It works great and gives you insight into what is executing when Dependabot runs just like any other GitHub workflow. The problem is that it has protection built-in to prevent the job from being re-run. I received a 201 when POSTing to /actions/jobs/JOB_ID/rerun and saw a new run kick off in my Actions tab but was ultimately stopped by: Dependabot workflows cannot be re-run. Retrigger this update via Dependabot instead. which comes from this dependabot-core logic. It seems to be fairly locked down.

[0xdevalias]

The problem is that it has protection built-in to prevent the job from being re-run.

@nmiddendorff Ah, true. That's annoying then :(

I haven't really looked, but are there API's that would let you re-trigger the dependabot run in a more 'roundabout' way? Alternatively, you could probably fork the action and just patch that line out right?

[jeffwidman]

As pointed out by @0xdevalias, we are migrating the back-end to use GitHub Actions.

It's true we've had to lock down the "re-run Dependabot" to avoid recursive loops (ie, misconfigurations keep looping) and security reasons.

But for the other use cases mentioned in this issue, the move to Actions gives us all those hooks/events for free and much more extensively then if we'd tried to build out our own bespoke version. 🎉