feat: Adds autobuild trigger workflow to avoid the auto-disabling on build loop job

[daghaian]

What changed

The Build Loop workflow was being automatically disabled by GitHub after each run (manual or scheduled), preventing subsequent scheduled builds from firing. The root cause is a known GitHub Actions behavior where workflows with a schedule trigger can be auto-disabled under certain conditions.

Why

Scheduled builds were silently failing to run, which breaks the expected automated build cadence.

Solution

• Removed the schedule trigger from the Build Loop workflow
• Introduced a new trigger_build workflow that owns the schedule, re-enables the Build Loop workflow before each run, and then dispatches it via workflow_dispatch

This sidesteps GitHub's auto-disable behavior by keeping the scheduled entry point in a separate, lightweight workflow that re-activates the primary one before triggering it.

Testing

• Manually triggered trigger_build and confirmed it re-enabled and dispatched Build Loop successfully
• Verified scheduled runs now fire as expected

Review notes

The logic change is isolated to workflow files only — no app code is affected. The main thing worth validating is that the workflow_dispatch + re-enable sequence in trigger_build is robust across the expected trigger scenarios (scheduled, manual).

[marionbarker]

Test

✅ successful test

Test Details

For testing purposes, I modified the files to trigger Wed at 5:33 pm PDT (00:33 Thursday UTC) and modified to check for the 4th week (instead of 2nd) to require a build regardless of new commits.

In usual GitHub fashion, this did not trigger until much later. But at 9:46 pm Wed, the trigger build did run and it did successfully enable the build and start the build.

• ✅ Scheduled Trigger Build
• ✅ Successful Build started by Trigger Build
  • Note - this shows up as a manually run by me, but was actually started by the trigger build action

The build completed and was uploaded to TestFlight. I successfully installed this build on my test phone.

Note in the screenshot below that once again Build Loop is disabled.

[marionbarker]

Next steps

Thank you so much for this proposal @daghaian

Let's think about modifications to prevent changing too much in the way of much documentation.

Would it work to modify the job name to 4. Build Loop inside trigger_build.yml and a different (and unnumbered job name in build_loop.yml, (backend-build-process or something else).

Then we can just add words that 4. Build Loop triggers the process that actually does the build and is able to run without being disabled by GitHub.