Skip to content

build(ci): drop the nightly schedule of the standalone crash-recovery lane - #973

Open
pasrom wants to merge 1 commit into
mainfrom
build/dedupe-nightly-e2e
Open

pasrom wants to merge 1 commit into
mainfrom
build/dedupe-nightly-e2e

Conversation

@pasrom

@pasrom pasrom commented Nov 12, 2026

Copy link
Copy Markdown
Owner

What

e2e-crash-recovery.yml ran every night at 06:15 UTC. e2e-app.yml already runs the same driver with the same flag (e2e-app.sh --no-build --crash-recovery) as its last lane, every night, on every push to main and on the run-e2e label, and that step is not continue-on-error. The standalone schedule therefore repeated the same assertions against the same commit on the one self-hosted machine, about ten minutes per night for no new evidence.

This removes only the schedule: trigger. The workflow keeps workflow_dispatch and the run-e2e label trigger, where it runs the lane alone on a fresh build of its own. Its header gave a reason for the separate nightly (the SIGKILL and relaunch would disrupt the other lanes of e2e-app) that no longer described the setup, because the e2e-app step runs after every other lane for exactly that reason; the header and the comment on the e2e-app step now say where the automatic coverage comes from.

Deliberately not changed

e2e-channel-fault.yml also has its own nightly slot (05:45 UTC) next to a step in e2e-app.yml, but that is not a duplicate: the e2e-app step is continue-on-error: true, so a regression there leaves the run green, and the standalone workflow is the only nightly that turns red. Removing its schedule would lose that signal.

Tests

  • actionlint on both edited workflows: no findings beyond the audio runner label it does not know, which main reports as well.
  • All 39 scripts/tests/test_*.sh pass.
  • No workflow was run for this change; the claim that both runs execute the same assertions rests on reading the two call sites.
  • Neither a ruleset, branch protection nor a doc references the removed schedule.

AI assistance

Written with Claude (Opus 5.5): the comparison of the two lanes, the change and the commit message. Reviewed and re-verified locally with Claude (Fable 5.2): diff and both call sites read, workflow lint and script tests repeated.

Checklist

  • Workflow lint, scripts/tests/test_*.sh
  • Conventional Commits, atomic, rebased on main

… lane

e2e-app.yml has run the same driver with the same flag as its last lane
(`e2e-app.sh --no-build --crash-recovery`, not continue-on-error) every
night since the lane was added there, and on every push to main. The
06:15 UTC schedule of e2e-crash-recovery.yml therefore ran the same
assertions a second time against the same commit on the one self-hosted
machine, about ten minutes per night for no new evidence.

The reason its header gave for a separate nightly, that the SIGKILL and
relaunch would disrupt e2e-app's other lanes, no longer described the
setup: the e2e-app step runs after every other lane for exactly that
reason. The header now says where the automatic coverage comes from.

The workflow keeps its dispatch and run-e2e label triggers, which run
the lane alone on a fresh build of its own. No required check, ruleset
or doc references the schedule.
@pasrom pasrom added the chore Maintenance or non-functional changes label Nov 12, 2026
@codecov

codecov Bot commented Nov 12, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.9%. Comparing base (6f9b9ce) to head (299b360).

Additional details and impacted files

Impacted file tree graph

@@           Coverage Diff           @@
##            main    #973     +/-   ##
=======================================
- Coverage   91.9%   91.9%   -0.1%     
=======================================
  Files        317     317             
  Lines      24317   24317             
  Branches       6       6             
=======================================
- Hits       22356   22355      -1     
- Misses      1957    1958      +1     
  Partials       4       4             
Flag Coverage Δ
appstore 92.2% <ø> (-0.1%) ⬇️
audiotap 92.0% <ø> (ø)
homebrew 91.9% <ø> (+<0.1%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 2 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

chore Maintenance or non-functional changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant