Bug: Idle scheduled workflow disabling also disables non-scheduled triggers

[l0b0]

Describe the bug

The "feature" which disables scheduled workflows after 60 days of inactivity also disables non-scheduled triggers of the same workflow.

Also, scheduled workflows should be re-enabled when there is activity, such as creating a new PR on the project.

To Reproduce
Steps to reproduce the behaviour:

1. Create a .github/workflows/test.yml workflow with the following triggers:

   on:
     pull_request:
       types: [opened, reopened, synchronize]
     schedule:
       - cron: '0 12 * * 0'
   

2. Wait for 60 days so the test workflow is disabled

3. Create pull request in the repo

Expected behaviour

The test workflow should run.

Actual behaviour

The workflow does not run, and there is no indication of why. I only managed to figure out why by seeing some kind of new link in the /actions page, clicking on it, seeing a message about the scheduled workflow being disabled, and re-enabling it. (I can't get a screenshot without waiting another 60 days for the workflow to be disabled again.)

[webknjaz]

Yeah, because of this I've been considering putting everything in a reusable workflow and including it into two separate workflow with different sets of triggers...

[at055612]

Seen the same thing. Workflow was disabled due to no commits in 60days. I also didn't know about this "feature". It would be nice to have some indication on the main Actions page to indicate a workflow is disabled rather than having to click into the workflow to find out. Pushing a new commit did not trigger the workflow as I would expect. By all means disable the scheduling, but not the whole workflow.

Agree that a new commit/pr/etc should automatically re-enable the scheduled runs. Also if the goal is to stop scheduled jobs running pointlessly and wasting resources, add some kind of option that will skip the scheduled run if there have been no commits since the last scheduled run. For a lot of people this would fit their use case and would reduced the number of scheduled job runs. My workflow already has this logic built in, if the head commit is the same as the last run then drop out, but this requires spinning up the workflow container/VM to make that decision.

[Jj0YzL5nvJ]

This issue in live:
mupen64plus/mupen64plus-rsp-z64#15
mupen64plus/mupen64plus-rsp-cxd4#61
mupen64plus/mupen64plus-video-z64#22
mupen64plus/mupen64plus-video-glide64#24
mupen64plus/mupen64plus-video-arachnoid#15
mupen64plus/mupen64plus-video-rice#108

The funny thing is that this does not disable scheduled builds that exceed said 60 days, now I understand why some people create scheduled tasks "to maintain activity" (scheduled commits...).

[jasonkarns]

Dupe of this opened here: https://github.com/orgs/community/discussions/66834

[pmonks]

Note that https://github.com/orgs/community/discussions/66834 goes into more detail about potential solutions, and the pros and cons of each, so it's worth reviewing even though it's now closed.

[jrochkind]

This has been hugely problematic for me -- I grasp that scheduled runs will be be disabled after inactivity, and grasp the motivation.

But every time I have a new PR on a stable project that's been idle for a while, and CI isn't runnign on it -- each time I end up forgetting how this works, takes me a while to remember why its' not working after being banging my head against the desk for a bit, then a while longer to remember how to re-enable it (and even once I do, I need to get an empty commit to the PR branch to actually trigger the CI now that it's re-enabled).

It's been quite disruptive to me, who maintains a fair number of stable not a lot of activity but still in use things.

It does make me want to consider putting in the workarounds that other people are using to artificially keep it from ever registering as idle -- which seems kind of rude, I get why you don't want to run scheduled things forever on an abandoned repo.... I'd accept that if it didn't also have this side effect!