githubgithub-apigithub-actions

Prevent scheduled GitHub Actions from becoming disabled


I am a maintainer of a few Julia GitHub repositories which use GitHub Actions for nightly CI runs, via cron. Some of these packages do not get maintenance for months but are used within the ecosystem and I'd like to keep them active. GitHub's current policy is to disable these actions when no repository activity has occurred in 60 days.

I'm wondering if there is a definition for what repository activity is to prevent actions from being disabled. Is this something as simple as commenting on an issue? Or do commits need to be pushed to the main branch?

Secondly, has anyone found a good solution for keeping repositories active? I was thinking of creating a Lambda function which runs every 59 days, and performs some form of repository activity to keep things alive. I've only found this HackerNews post which brings this up, however there are no comments:

Scheduled workflows will be disabled by default in forks of public repos and in public repos with no activity for 60 consecutive days. W e’re making two changes to the usage policy for GitHub Actions. These changes will enable GitHub Actions to scale with the incredible adoption we’ve seen from the GitHub community. Here’s a quick overview:

  1. Starting today, scheduled workflows will be disabled by default in new forks of public repositories.

  2. Scheduled workflows will be disabled in public repos with no activity for 60 consecutive days.


Solution

  • I was unable to find a resolution to this issue. Instead I've implemented a hopefully temporary solution to this problem.

    https://github.com/invenia/KeepActionsAlive

    This package uses AWS SAM to deploy a Lambda function. The function runs every 59 days, gathering all non-forked, non-archived repos for your organization. It will then hit the enable workflow REST API endpoint for all non-manually disabled workflows. There is functionality built in to support repos outside of an organization.

    It's very rudimentary, but for those already using AWS this should help fix the problem.