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.

[marionbarker]

Test

✅ This test was successful.

• I think a rename like this is a good idea.

❓ The thing we don't know and won't know is will the trigger_build.yml file also be disabled by GitHub when it reaches enough forks.

Test Details

Continuing to work in my docs-test organization, I modified the name for the jobs as follows:

diff --git a/.github/workflows/build_loop.yml b/.github/workflows/build_loop.yml

    -name: 5. Build Loop
    +name: background process that builds

diff --git a/.github/workflows/trigger_build.yml b/.github/workflows/trigger_build.yml

    -name: 4. Trigger Build Loop 
    +name: 4. Build Loop

I pushed this change to docs-test along with a modification to trigger the cron job today at 12:33 PDT (19:33 UTC).

Screenshot before job is triggered

Note that the job names now match what is in the documentation with the new trigger_build.yml job called 4. Build Loop and the build_loop.yml job called background process that builds showing up at the end with no number.

Note also that the build_loop.yml file (background process that builds) is disabled.

Screenshot after job is triggered

The new trigger_build.yml shows up as 4. Build Loop and it triggers as expected from the cron job. It kicks off the build_loop.yml file (background process that builds) which starts right away.

Note that build_loop.yml is already disabled again, but the build continues, and completed successfully.

[marionbarker]

There was some private communications back and forth. At one point David said just renaming the build file prevents to disabling. I tried this with a different branch: https://github.com/docs-test/LoopWorkspace/tree/test-simple-rename

I renamed the build_loop.yml file to build_loop_new.yml.
Then I modified the cron time so it would run sometime after 5:33 pm PDT Friday.

And it did automatically build and was not automatically disabled.

It may be easier just to rename and see if that fixes the issue. If that is later disabled, then we could try the trigger idea.

Feedback is desired.

[bjorkert]

Not sure about the "Why" here either. Just to make sure I understand the theory behind the rename approach: is the idea that GitHub has flagged this specific build_loop.yml as "problematic" and is auto-disabling it earlier than the normal 60-day inactivity rule, and that renaming the file sidesteps that flag (at least temporarily)?

My reasoning: a fork should normally stay "active" because the scheduled run syncs upstream and pushes those commits into the fork, which resets the 60-day clock (and upstream gets commits well within 60 days). That sync happens early in check_status, before the build job, so even if the build itself fails later (unsigned Apple agreement, inactive Apple account, or other common errors), the fork update has already landed and isn't affected. So if these forks are still being disabled, it doesn't look like the plain 60-day inactivity rule?

If we rename something, or create another scheduled workflow, I am afraid we are just moving the problem?

[marionbarker]

Comment

Another thing to consider is that many people have customizations included in their build_loop.yml file.
My build_loop_new.yml action in test-simple-rename branch is still enabled this morning, but this may change when that gets incorporated into the upstream LoopKit fork.

Next Idea

Instead of renaming. I'm going to try a copy, so we maintain build_loop.yml (unchanged except for nominal update for xcode version) in which I comment out the cron task and use 4. Build Loop Manual as the name and build_loop_auto.yml with the name 4. Build Loop Auto, which keeps the cron task.

I'll report back when this test is done.

[marionbarker]

This is the status of the test-simple-copy actions at docs-test.

Ignore the error in the graphic - I initially failed to comment out the schedule line in addition to the cron line for build_loop.yml

Note that 4. Build Loop Manual is already showing as disabled. So it does appear to be associated with the filename.

[daghaian]

he "Why" here either. Just to make sure I understand the theory behind the rename approach: is the idea that GitHub has flagged this specific build_loop.yml as "problematic" and is auto-disabling it earlier than the normal 60-day inactivity rule, and that renaming the file sidesteps that flag (at lea

Hey @bjorkert, Marion did voice your thoughts on this, and I'll paste my response that I sent to her here:

"Re the concern, its completely valid. I have no proof to suggest that this permanently resolves the issue because the original Build Loop was being disabled by "Github admin", and only for the singular repo.

This points to something from Github's end and not a user/organization setting, since seemingly it only targeted Loop (and no other forked repos with the same exact workflows).

This to me indicates something outside of our control.

Best case: Trigger works to kick whatever bug GitHub has on their backend
Worst case: Trigger gets disabled at which point nothing changes from the current state, as you pointed out

I have gone through the audit log for the forked repo, and we see that "Github Admin" is responsible for the repeated disabling of the "Build Loop" workflow. While I have no clear way to confirm this, I'm wondering if this behavior (since it only affects LoopWorkspace) could be a byproduct of the number of repo forks (7.8k+) compared to Trio's ~1k. Additionally, if it were an organizational setting/personal Github setting, then the creation of additional scheduled workflows as well as the rename approach mentioned above would not have resolved the issue. I would find it very hard to believe that there was some hidden setting only affecting the build_loop.yml workflow for users who fork the repo.

In my opinion, we have nothing to lose by trying either the trigger or the rename-based approach in the long term

[marionbarker]

test-simple-copy

The test-simple-copy branch, commit da934e4, changed the cron time for build_loop_auto.yml to run shortly after the commit was pushed to docs-build.

As seen in the screenshot below, the scheduled process ran but did not build because today is not the 2nd Saturday of the month.

A subsequent commit changed both the time and the day of the week. I'll report back later to confirm that the process both started as scheduled and completed a build.

[marionbarker]

test-simple-copy

The test-simple-copy branch, commit bb2176c, changed the cron time for build_loop_auto.yml to run shortly after the commit was pushed to docs-build and modify the build to be on the 4th Saturday of the month.

As seen in the screenshot below, the scheduled process ran and did build successfully.

[marionbarker]

Proposal

I think we should go with the change made in docs-test in which

• build_loop.yml was copied to build_loop_auto.yml (so both files are included)
• the internal names were changed to 4. Build Loop Manual (for build_loop.yml) and 4. Build Loop Auto for build_loop_auto.yml
• the schedule and cron lines were commented out of build_loop.yml

See these two commits to see those changes (I forgot to comment out the schedule line in the first commit):

• docs-test@7b15d3e
• docs-test@da934e4

David - please don't do a force push to make these changes. I will be doing a squash and merge when I bring this change in so there will only be a single commit that shows up.

Discussion

I welcome discussion on this.

The 4. Build Loop Manual will maintain the original users customizations. They can transfer those to 4. Build Loop Auto if the automatic build stays enabled. Users can continue to build manually if they prefer.