Let me answer your first question (apparently nobody bothered to answer) first:
What's going on?
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?
According to the GitHub docs workflows are "automatically disabled when no repository activity has occurred in 60 days". The GitHub docs don't elaborate on what this means exactly, thus the exact definition might change.
From observation we know that GitHub requires you to push commits. Just commenting on issues is not sufficient to keep workflows alive.
How to fix it
Secondly, has anyone found a good solution for keeping repositories active?
Yes, there are numerous solutions to keep a repository's workflows alive despite the 60 days limit. A few have been mentioned in this question already, but there are some more and new one's pop up from time to time. However, since you only need one, I don't see much reason to create a complete list.
All solutions can be boiled down to basically two approaches:
Using the GitHub API to re-enable disabled GitHub workflows. Since GitHub introduced this limitation it was believed that this approach only works when the GitHub workflow has been disabled already, thus it was believed that only another server could do this (like with Matthew's recommended invenia/KeepActionsAlive). However, this isn't true - see below.
Add empty "ghost/dummy" commits to the repo to spoof activity. This has many disadvantages, like cluttering your repo with useless empty commits possibly triggering other workflows, issues with protected branches, requiring way to powerful access (i.e. security risks), etc. This approach (as used by e.g. Jack's recommended gautamkrishnar/keepalive-workflow till 2024) was predominant since GitHub introduced this limitation.
AFAIK I was the first one to notice in 2022 that the supposed limitation of the API approach isn't really true (but I might be wrong, I just did extensive research back then and looked into all existing solutions at that time and didn't find a single one using that approach): Enabling a workflow even if it hasn't been disabled yet resets the 60 days timer.
I therefore created my own, fully configurable solution back in 2022 requiring neither an external server, nor to create "ghost/dummy" commits. Since it has some more advantages (better configurability, better logging, support for multiple repos, support for execution on the local machine, …) I want to present it below as my recommended solution nevertheless.
My recommendation
As explained earlier I've created a GitHub action ("GitHub Workflow Immortality") to solve this task back in 2022.
https://github.com/marketplace/actions/github-workflow-immortality
Using the GitHub action is pretty straight-forward:
First create a personal access token (PAT). A classic PAT is simplest and always works, but fine-grained PATs are supported to. See the action's docs to learn about the differences of fine-grained and classic PATs.
Then create an encrypted secret called PERSONAL_ACCESS_TOKEN in either some (new) meta repo, or the repo whose workflows you want to keep alive.
Last but not least create the GitHub workflow .github/gh-workflow-immortality.yml (i.e. just create and push that new file to your repo) like the following and incorporate the GitHub action as its only step:
name: GitHub Workflow Immortality
on:
schedule:
# run once a month on the first day of the month at 00:20 UTC
- cron: '20 0 1 * *'
workflow_dispatch: {}
jobs:
keepalive:
name: GitHub Workflow Immortality
runs-on: ubuntu-latest
permissions: {}
steps:
- name: Keep cronjob based triggers of GitHub workflows alive
uses: PhrozenByte/gh-workflow-immortality@v1
with:
secret: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
repos: ${{ github.repository }}
If you want to use a meta repo to keep the workflows of multiple repos alive, you might want to replace repos: ${{ github.repository }} by either a list of repos, or by the users and/or orgs config taking GitHub usernames resp. organization names. See the GitHub action's docs for more info about that.
Unlike the other solutions this GitHub action is fully configurable and allows not just to keep the workflows of the same repo alive, but of arbitrary repos as well (as long as the configured PAT has permission to do so). This e.g. allows one to use a single "keep alive" workflow (e.g. in the user's or organization's meta repository) to keep all workflows of a GitHub user and/or organization alive. Just do so and you don't have to ever think about the matter again.
As final note, the GitHub action wraps a simple Bash script, thus you can run it locally for testing purposes, too. However, the script provides some pretty decent logging and tells what's going on, so you likely don't have to; but if you have to, you can. The script doesn't depend on any external tools besides the usually pre-installed curl and jq (i.e. you don't have to install the huge GitHub CLI just to perform such small task).
