Add a job to report status of repo builds

[rebkwok]

Get BennettBot to show a dashboard of repo builds.

With the CLI, we can get a repo of the workflow runs for the latest commit on main

gh run list -c $(git log -n 1 main --pretty=format:"%H")

We should be able to use the GitHub API to get the same: https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2022-11-28#list-workflow-runs-for-a-repository

And we can use Slack's block formattingto make a nicely formatted report that we can put in #tech with a slack reminder each morning, like we do for team reports.

See https://bennettoxford.slack.com/archives/C63UXGB8E/p1725531792391249

[alarthast]

After discussion with Becky:

• There are actions that are automatically triggered (i.e. not by a commit) which we would like to track, so let's not use commits to find the workflow runs
• Approach: Find the workflow IDs for each repo --> Check the status of the latest run of each workflow ID (Should be success although need to check if "Skipped" shows up)

For the current repo (as an example), the endpoints are: https://api.github.com/repos/ebmdatalab/ebmbot/actions/workflows https://api.github.com/repos/ebmdatalab/ebmbot/actions/runs?branch=main

[alarthast]

There are workflows that do not run on main but in other branches.

There might be several ways to handle this:

1. Somehow flag a workflow not meant for main and skip it
2. If a workflow does not appear within the last ~1000 runs on main, ignore it
3. 2 but instead of ignoring it, show the status of the last run regardless of which branch it was on

Complexity of coding is 2 < 3 << 1 (since 1 probably means that there needs to be a file accessible to BennettBot that documents workflows to be ignored?)

[rebkwok]

In the case of that specific Airlock workflow, I don't think we care about it - it's there to deploy a preview site for the docs on branches where the docs have changed. If it fails, it's only an issue for the branch and for the person making a PR from it, so we don't want it to show up in a dashboard and imply something isn't working on main. I think probably the same is true for any other workflows that explicitly ignore main (I'm not sure if we have any others that do. Possibly a similar ehrql docs one.)

If we have only a very few of these, adding their IDs as an env var/global/config of some sort to bennettbot should be fine. We probably also want to ignore any that don't appear on main, in case there are new ones that are added. How do the main workflow runs appear in the api response? Does it need to check back as far as 1000 runs?