Safari / Safari Technology Preview runs aren't actually running on the epochs

[gsnedders]

This e.g. led to https://github.com/web-platform-tests/wpt/actions/runs/11357446457 and https://github.com/web-platform-tests/wpt/actions/runs/11358412726 to both run against 3585305 (which was current master when both ran), instead of 100f904 and 3585305 respectively (see the respective epoch jobs: https://github.com/web-platform-tests/wpt/actions/runs/11357430600 and https://github.com/web-platform-tests/wpt/actions/runs/11358394569).

I think this should be as simple as telling actions/checkout what to checkout at:

wpt/.github/workflows/safari_technology_preview.yml

Lines 47 to 50 in 00e1df7

	- name: checkout
	uses: actions/[email protected]
	with:
	fetch-depth: 1

That said, merely passing fromJSON(needs.check-workflow-run.outputs.updated-refs)[0] will result in the runs being non-rerunnable, as they'll always run against whatever refs/heads/epochs/three_hourly then is. This is probably still a net-win, even if it's only a partial fix.

We probably ultimately want .github/workflows/check-workflow-run.yml to return an object like {"refs/heads/epochs/three_hourly": "100f9048d8"}. Or just return the shas.

[gsnedders]

This shows potentially one major downside of using workflow_run to trigger the safari_technology_preview workflow on completion of the epochs workflow; if we instead used workflow_dispatch from epochs then that could trigger the workflow with the correct ref — but then the epochs workflow needs to know about safari_technology_preview. See #48031.

[gsnedders]

To summarize the status quo, given @jgraham asked why we can't use the workflow_run event:

The workflow_run event payload data doesn't help us much, as it mostly just lets us know that we were triggered by the epochs workflow completing, and that the epochs workflow ran against the master branch.

That doesn't tell us what epochs (if any!) got updated, so we can't get out of having to pass the ref we want to run ourselves.

Currently, we store the output of git-push --porcelain as an artifact on the epochs workflow run, which we then download (and parse) in the workflow where we actually invoke wptrunner to check that the ref we care about got updated.

Further, to make the runs re-runnable, we need to know not just what refs got updated, but what they got updated to.

And finally we then need to tell wpt.fyi, when uploading results, both what ref we ran and what commit we ran against. and we need to be able to trust that — which we admittedly probably can for runs on the default branch on the upstream repo. But it becomes an oddity where we can't trust the workflow run metadata to tell us what was being run — as that will always be the latest commit on master, because workflow_run always runs against the default branch.

---

The more I consider our possibilities here, I really do think going back on the previous decision to use workflow_run is the right one, as if we move to workflow_dispatch we can just pass the relevant ref and then re-runs work as expected, the run metadata is what would be expected, etc.