Mark scheduled runs with nothing to build as cancelled instead of successful

[bjorkert]

Problem

The scheduled weekly run checks for new commits and only builds when something changed (or when the monthly forced build is due). When there is nothing to build, the build jobs are skipped and the run still completes with a green check — indistinguishable at a glance from a successful build. Users who rely on the green status can believe they have a fresh build even when their last real build attempt failed.

Change

A new cancel_when_no_build job in build_LoopFollow.yml fires only on scheduled runs where the build gate is false (no new commits and no monthly build due) and cancels its own run, so it shows as cancelled (grey) instead of successful.

Status semantics after this change:

• green — a new build was made and uploaded to TestFlight
• cancelled (grey) — the repository was already up to date, nothing was built
• red — a build was attempted and failed

Details:

• Manual (workflow_dispatch) runs always build and are unaffected.
• The job condition is the exact negation of the check_certs/build gate restricted to schedule events, so it can never fire alongside a build.
• Cancellation uses the run's own GITHUB_TOKEN with job-level actions: write — no new secrets and no third-party actions. The trailing sleep keeps the job alive until the cancellation lands, so the run cannot complete as successful first.
• Forks with SCHEDULED_SYNC/SCHEDULED_BUILD set to false also see cancelled instead of green on scheduled runs, consistent with green meaning "built".
• With GitHub's default "Only notify for failed workflows" notification setting, cancelled runs do not generate notification emails.

fastlane/testflight.md is updated to describe the new cancelled status, and its stale schedule description is corrected (checks run on Sundays with the forced monthly build on the second Sunday; the text still said Wednesdays / first of the month).

[marionbarker]

Test

✅ successful test

Configuration

Push the branch to docs-test organization, make it the default branch and then modify the cron and week of month values to test various situations

Test: no regression when cron fires and it is selected week of month

• ✅ Successful Build with green check mark

Test: new feature, build skip shows as cancel job (no green check)

The cron was slow to fire so I updated the cron time in case I made a mistake, and they both fired

• ! Successful Skip with cancel sign
• ! Successful Skip with cancel sign

Test: no regression when cron fires and an update is detected even if not selected week of month

Updated the testflight.md instructions and pushed that commit to origin.

• ✅ Successful Build with green check mark

[marionbarker]

Approved by code review and test.