#55589: build: use nightly publish time for the benchmarks stale-nightly skip
Requested by John Kleinschmidt · Slack thread
Description of Change
Follow-up to #55482. The scheduled Benchmarks run (daily at 20:43 UTC) skips the latest nightly when it is more than 24 hours old, but it measured that age from midnight UTC of the nightly's release date, because releases.json only records a date. A nightly published after the evening run on its release day was therefore already about 45 hours old at the next day's run and was never benchmarked. For example, 47.0.0-nightly.20261030 was published at 23:42 UTC.
The skip now measures the age from the nightly's GitHub release published_at in electron/nightlies (read with the job's read-only GITHUB_TOKEN), and the threshold is 25 hours, so a daily run that starts up to an hour later than the previous one still picks up a nightly published just after it. If the API call fails, the script warns and falls back to the date-based age. Manual dispatches and explicit candidates are unaffected. One edge case remains: a nightly published less than an hour before a run can be benchmarked by two consecutive runs. Nightlies normally publish between 14:30 and 18:00 UTC, so this is rare.
The tests use a mocked fetch. They cover a nightly published at 17:00 UTC (it runs that evening and is skipped the next evening), the 23:42 UTC case (it runs the following evening, where the date-based age would have skipped it), and the fallback. A local schedule-mode run against the live nightlies printed 47.0.0-nightly.20261102 was published at 2026-11-02T17:00:48.000Z and nothing to do: the latest nightly is 31 hours old.
Checklist
- I have built and tested this change
- I have filled out the PR description
- I have reviewed and verified the changes
- tests are changed or added
Release Notes
Notes: none
Generated by Claude Code
Backports
No Backports Requested
This pull request doesn't have any backports requested or created for older release branches.
What are backports?
Backports are copies of changes made to the main branch that are applied to older release branches. They ensure that bug fixes and important changes are available in maintained older versions of Electron.
Semver Impact
Semantic Versioning helps users understand the impact of updates:
- Major (X.y.z): Breaking changes that may require code modifications
- Minor (x.Y.z): New features that maintain backward compatibility
- Patch (x.y.Z): Bug fixes that don't change the API
- None: Changes that don't affect using facing parts of Electron