Job step boundaries may be unreliable when GitHub returns flat log format

[thomasjm]

Problem

When viewing job logs in sauron, step boundaries (i.e. which job step a log line belongs to) may be inaccurate for some workflow runs.

Background

GitHub's workflow logs zip file API sometimes includes per-step log files (e.g. JobName/1_SetUpJob.txt, JobName/2_Checkout.txt) and sometimes only a single flat file per job (e.g. 0_JobName.txt). Per a gh CLI maintainer (cli/cli#10551):

Sometimes, the ZIP archive includes the logs for the individual steps, sometimes it's not. This is due to the internals of the API back-end. [...] Unfortunately, we don't yet have a full understanding about the underlying causes and we're still following up on this internally.

Current workaround

When sauron receives a flat log file, it splits the combined log into steps using timestamp-based heuristics. The JobStep metadata from the GitHub API provides started_at and completed_at timestamps, but these are truncated to whole-second granularity. Since many steps complete within the same second (especially short setup steps), log lines can end up assigned to the wrong step. We also show a warning in the job node box.

Related issues

• cli/cli#10551 — --log no longer produces logs
• cli/cli PR #10740 — fallback to flat job logs with UNKNOWN STEP label