Job execution time in GitHub Check Suites is not accurate for jobs with dependency

[emilyalbini]

It looks like that jobs with dependencies (like "deploy" in omicron) have their execution time in GitHub Check Suites tracked as the time it took to complete the dependencies and the job in question. This makes it harder to determine how much the job actually takes, and is not consistent with how GitHub Actions tracks things. We should switch it to track only the time it took to complete the job itself.

[jclulow]

I don't know that we actually have much control over this? We report the check run as queued to GitHub while it is waiting for dependencies.

GitHub has of course chosen to privilege Actions in an anti-competitive way, which means we often don't have the same level of control over our check suites/runs that they do internally. For example:

From https://docs.github.com/en/rest/guides/using-the-rest-api-to-interact-with-checks?apiVersion=2022-11-28#about-check-runs

The status can be queued, in_progress, requested, waiting, pending, or completed. Only GitHub Actions can set a status of requested, waiting, or pending.

It seems likely that waiting might actually help with this issue, but it isn't available which is why we represent jobs as queued instead. Mind you, it doesn't seem right for them to reflect queued time as if it were execution time either, but it's not really surprising that they've muddled that up.

[emilyalbini]

I did some tests with a sample GitHub App of mine, and this should actually be doable. The started_at field can be tweaked to an arbitrary timestamp, which then gets immediately reflected in the UI:

gh api -X PATCH repos/emilyalbini/test-repo/check-runs/66602143254 -f 'started_at=2026-03-11T10:05:50Z'

So what we can do is override it to the current time when a worker gets assigned to the job. I'll work on a PR for this!