Do disabled scheduled workflows re-activate on repository activity?

As of now, after 60 days without repo activity scheduled workflows deactivate automatically. My question is: do these workflows re-activate automatically with new repo activity? If not, is there a way to make them do so?

I can tell you for a fact they are not automatically reactivated on repo activity as I just ran into this myself.

I’m looking for a solution to this as well.

Use-case:

  • Repo with little activity but with a tight coupling with some external projects.
  • One workflow.
  • This workflow is used for CI/required statuses for pull requests.
  • This same workflow has a scheduled cron job once a month as an early warning system to get notice if one of the external projects has changed in such a way as that the code in the repo would need to be updated.

The workflow was deactivated after sixty days of inactivity, which has two side-effects:

  1. The “early warning” system is disabled, making having it in place in the first place kind of useless if it gets auto-disabled after two runs.
  2. As the same workflow is used for required statuses, new PRs which were submitted become unmergable until 1) the workflow is manually re-enabled, 2) the PRs are force-pushed without changes to trigger the workflow.

This kind of defeats the point of having CI in place…

2 Likes

I just left this feedback on the GH Docs page about the auto-disabling. :crossed_fingers: someone actually reads it (and hopefully takes action)…

The automatic disabling of workflows breaks essential functionality, like required statuses. It also kind of defeats the point of having the ability to use cron jobs.

I need to find a way to either turn off the auto-deactivate or to automate turning the workflows back on.

For a full description of the use case, please see: Do disabled scheduled workflows re-activate on repository activity? - #2 by jrfnl

I do understand the need to conserve resources, but that can be managed differently.
As a suggestion - instead of using the hard sixty-days cut-off, would it be an option to set the limit based on usage ?
Say: 30 runs.

For a repo with little activity and a daily cronjob, that would mean, the workflow would get auto-deactivated after 30 days.

For a repo with little activity and a montly cronjob, that would mean, the workflow would get auto-deactivated after 30 months.

2 Likes