ci: report hardware-lab release-QA as a check-run - #1907
Conversation
…mits The release-QA pass runs in coredevices/unicorn on a real phone + watch. A PAT can't create check-runs and unicorn's GITHUB_TOKEN is scoped to unicorn, so unicorn fires a repository_dispatch here and this workflow's github-actions token creates the check-run, giving a PR a 'release-qa (hardware lab)' entry in its Checks tab. release-qa-start marks it in_progress; release-qa-result completes it with success/failure and a link to the run's full breakdown. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Eric Migicovsky <eric@repebble.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f9f0e27f1e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const { data } = await github.rest.checks.listForRef({ owner, repo, ref: sha, check_name: name }) | ||
| const existing = data.check_runs && data.check_runs[0] |
There was a problem hiding this comment.
When two hardware-lab passes overlap for the same SHA, this lookup identifies a check only by commit and name, so both passes update the same entry: the first result can mark the check completed while the second pass is still running, and a later result can overwrite it again. Concurrent start/result workflow jobs can also both observe no existing run and create duplicate entries. Include a unique run identifier in the dispatch payload (for example via external_id) and use it to select the matching check run.
Useful? React with 👍 / 👎.
|
Closing — the unicorn/release-qa commit status already gives parity with unicorn/smoke (which is also a commit status, not a check-run) and shows in the PR's checks list. Not worth the extra repository_dispatch machinery for a separate Checks-tab entry. |
1 participant
What
Adds
.github/workflows/release-qa-check.yml— a tinyrepository_dispatchworkflow that turns the hardware-lab release-QA result (run in coredevices/unicorn on a real phone + watch) into a check-run on a PebbleOS commit, so a PR shows arelease-qa (hardware lab)entry in its Checks tab.release-qa-start→ in_progress check-run (the pass is running).release-qa-result→ completed check-run, conclusionsuccess/failure,details_url→ the unicorn run (per-stage PASS/FAIL table, logs, screenshots, video).Why not a commit status?
The unicorn dispatch already posts a
unicorn/release-qacommit status, which shows in the PR merge box — but the Checks tab only lists check-runs, and a PAT can't create those (the Checks API rejects PATs) while unicorn'sGITHUB_TOKENis scoped to unicorn. Firing arepository_dispatchinto PebbleOS lets this workflow'sgithub-actionstoken create the check-run natively.A follow-up unicorn change fires
release-qa-start/release-qa-resultat the run's begin/end.repository_dispatchonly triggers workflows on the default branch, so this must land onmainbefore it's live.🤖 Generated with Claude Code