Scheduled action in fork keeps getting disabled

[marionbarker]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

Schedule & Cron Jobs

Discussion Details

Overview

There are a number of individuals who support their treatment of Diabetes using one or more open-source apps.

We share the code for the .github/workflows/build_xxx.yml files freely among these Diabetes open-source apps. They are not all identical but are substantially the same. The newest version, included in LoopWorkpace, dramatically minimizes the number of runners used and shifts the scheduled time to weekends when GitHub tends to be less busy.

The Problem

One of the apps (but only one) will not stay "enabled".
The app is active and has recent commits in the upstream repository.

• Scheduled build action does not run because it is "disabled"
• Must first enable the build action
• Manually run the build action (which is successful)
• GitHub automatically disables that action

Source Repositories

This is a partial list of the open-source apps that are actively in use by people who rely on scheduled updates to bring in new versions to their TestFlight app.

Open-Source App	Schedule OK?	Forks	Link
Loop	❌	7.1k	https://github.com/LoopKit/LoopWorkspace
Trio	✅	1.2k	https://github.com/nightscout/Trio
LoopFollow	✅	1.0k	https://github.com/loopandlearn/LoopFollow

Fork that is automatically disabled

This is an example of a fork from the LoopKit/LoopWorkspace repository which is automatically disabled following manual run. It is hosted in a free GitHub organization. Note that we recommended use of a free organization for people who build more than one app. This way they only need to enter the Secrets one time to build the apps.

• https://github.com/docs-test/LoopWorkspace/actions/workflows/build_loop.yml

Forks from a different source repo without the problem

Here are a few examples of forks in the same free GitHub organization for which the scheduled builds are fine.

• https://github.com/docs-test/Trio/actions/workflows/build_trio.yml
• https://github.com/docs-test/LoopFollow/actions/workflows/build_LoopFollow.yml

[Nixxx19]

Hey! @marionbarker, I saw your profile and I’m impressed with your work.

Why this happens

• GitHub disables scheduled workflows in forks by default (forks of public repos). :contentReference[oaicite:1]{index=1}
• GitHub also automatically disables scheduled workflows in public repos that have had no repository activity for 60 consecutive days. :contentReference[oaicite:2]{index=2}
• Org or repo Actions policy can prevent or re-disable workflows (Actions permissions / allowed actions). :contentReference[oaicite:3]{index=3}

What to check (quick)

1. Repo Settings → Actions → General

   • Ensure Actions are enabled for the fork and that workflows are allowed.
   • If your organization restricts Actions, the org policy may be re-applying and disabling schedules. :contentReference[oaicite:4]{index=4}

2. Workflow status in the fork

   • Open the workflow file page (Actions → the workflow) and confirm it’s enabled. If it’s enabled and later disabled, note the timestamp and who (or what) disabled it.

3. Activity window

   • Has the fork been idle >60 days? If so, scheduled jobs can be auto-disabled. Add some repository activity or keep it in sync with upstream. :contentReference[oaicite:5]{index=5}

4. Upstream vs fork behavior

   • If you don’t need the cron to run in forks, guard your jobs so schedules only run in the upstream repo:

     jobs:
       build:
         if: ${{ github.event.repository.fork == false || github.event_name != 'schedule' }}

     That prevents forks from even attempting scheduled runs (and avoids churn). :contentReference[oaicite:6]{index=6}

5. Organization-level reconfiguration

   • If the fork lives in an organization, check the org Actions policies (Owners can change). A policy may disable or limit scheduled workflows periodically. :contentReference[oaicite:7]{index=7}

Fixes / workarounds

• Enable the workflow manually in the fork and ensure the repo has some recent activity (commits, pushes) so it won’t be auto-disabled for inactivity. :contentReference[oaicite:8]{index=8}
• Move scheduled jobs to the upstream repo (preferred): keep the cron in the canonical repo so forks don’t need schedules at all.
• Add an if guard to skip schedule runs in forks (example above). This avoids the whole enable/disable dance. :contentReference[oaicite:9]{index=9}
• Check org settings and ask org owners to allow Actions for that repository if an org policy is clobbering your enable. :contentReference[oaicite:10]{index=10}
• If behavior is inexplicable, collect timestamps/screenshots and open a GitHub Support ticket; they can inspect if a platform policy or automated process is re-disabling it.

If you want, paste the fork repo URL here (or the Actions → workflow run logs / timestamps when it was disabled) and I’ll point to the precise setting most likely responsible.

Hope this helps, have a nice day!