Prevent scheduled workflow from being automatically disabled

[joverlee521]

Context

The GitHub workflow docs state:

In a public repository, scheduled workflows are automatically disabled when no repository activity has occurred in 60 days.

List of affected workflows

• status CI: manually re-enabled on 2024-09-10
• Update GitHub project: disabled on 2023-02-07 (previous issue)
• dengue ingest-to-phylo workflow: manually re-enabled on 2024-09-26
• rabies ingest-to-phylo workflow: manually re-enabled on 2024-10-29
• rsv fetch-and-ingest and rebuild workflows: manually re-enabled on 2024-11-04
• zika fetch-and-ingest: manually re-enabled on 2024-11-25

Possible solutions

1. Keep manually re-enabling affected workflows as they are noticed to be disabled
2. Use the Keepalive Workflow action on affected workflows
3. Create our own workflow that runs some activity as the Nextstrain bot. I'm not entirely sure what counts as "repository activity" but a couple options:
   • Push dummy commit to main
   • Push dummy commit to a long term "keep-alive" branch
   • Create and delete a new branch
   • Create and close a new issue
   • Other ideas?
4. ✅ Make a central keep-alive workflow that uses the GitHub REST API to disable/enable affected workflows every <60 days
5. ⛔️ Use Terraform run regularly to control this. The official GitHub provider for Terraform doesn't expose the endpoint we need.

[joverlee521]

Manually re-enabled the workflow for now and it will run as scheduled in ~5mins

[tsibley]

Similarly, I just re-enabled the dengue ingest-to-phylo workflow which got disabled due to repo inactivity.

[tsibley]

Maybe also worth pointing out that I noticed the dengue workflow being disabled thanks to the status page's time-relative layout.

[genehack]

Any objection to adding a keepalive step to these workflows to avoid this?

[victorlin]

^ that was one of the proposed solutions in nextstrain/project-board#5. I've copied all the relevant parts of that issue's description into this issue's descrpition.

[victorlin]

We should find a solution that doesn't require modifications to individual workflow files. Ideally, there would be an org-wide setting provided by GitHub to customize the amount of days of inactivity before automatic disabling. I wouldn't be surprised if they provide that in the future, at which point we would have to go back and undo modifications to individual workflows if we were to use something like gautamkrishnar/keepalive-workflow.

I think there is a solution that uses the GitHub REST API for enabling/disabling workflows. There can be a central workflow (e.g. nextstrain/.github/.github/workflows/keep-alive.yml) that has a list of scheduled workflows we want to keep alive and will periodically invoke the REST API to disable/enable each workflow. I imagine this list will also change over time, so having this central list will make this easier. Of course, we may still run into the issue of that central workflow being disabled, but in that case it makes sense to use gautamkrishnar/keepalive-workflow for just the one workflow.

[joverlee521]

@victorlin I like the idea of a central workflow! Looks like gautamkrishnar/keepalive-workflow@v2 started using the GitHub API to enable workflows under the hood. Maybe we can just use gautamkrishnar/keepalive-workflow@v2 in a single action matrix to keep multiple repo workflows enabled?

[tsibley]

I would avoid third-party code here. It feels like a risk that's not worth it.

I like Victor's idea of centralizing control over this rather than modifying each workflow.

A previous thought I'd had here, though it seems like I didn't express it, was to use Terraform run regularly to control this. (Although the official GitHub provider for Terraform doesn't expose the endpoint we need.)

[victorlin]

The API seems simple enough that we can call it directly and not through third-party code.

If folks are on board with the proposed approach (option 4), I'll move this issue to nextstrain/.github and make a PR there.

[genehack]

I'm mostly implementation-agnostic and generally agree a self-owned central workflow is probably better — the best overall solution is the one that will allow the issue to be closed 😉

[victorlin]

Thanks for transferring @joverlee521, I dropped the ball on this one. Probably not going to do this over the next few weeks so if anyone wants to take it, feel free.

[joverlee521]

I had to manually re-enable another workflow today, so I decided to pick this up -> #118.