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.

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.

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.

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.

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?

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.