Treat timing data collection errors as non-fatal

Lachlan Grantrequested to merge
1-fix-timing-fetch-fatal-error into main

Summary

splitic test fetches per-test timing data from a previous pipeline's test_report API endpoint before running any tests, to balance parallel shards. Any error from that fetch other than "no timing data available" was treated as fatal (os.Exit(1)), aborting the whole job before a single test ran.

A transient network hiccup talking to gitlab.com/api/v4 (10s ResponseHeaderTimeout) was enough to kill jobs with no test output and no artifacts produced. Observed causing gitlab-runner CI failures, e.g. https://gitlab.com/gitlab-org/gitlab-runner/-/jobs/15163231209:

error collecting timing information: performing timing request:
  Get "https://gitlab.com/api/v4/projects/250833/pipelines/2648455886/test_report":
  http2: timeout awaiting response headers

This treats all timing-fetch errors as non-fatal, warning and continuing without timing data, matching the existing behavior for "no timing data available".

Closes #1 (closed)

Test plan

  • go build ./... passes
  • go test ./internal/runner/... passes (pre-existing, unrelated build failure in internal/runner/flags on main is untouched by this change)

Merge request reports