Those badges are meant to be updated by the logic in https://github.com/Async-AWS-PR/commits-since-release-counter
However, scheduled workflows in GitHub Actions have a rule: they disable themselves if the repository has no activity in 60 days (they don't want to spend their resources for inactive repos, which is understandable for things they provide for free). As this repo is updated only when badges are updated, it means that the infrastructure breaks if we have 60 days without activity in the mono-repo.
A solution might be to have this update be triggered by a workflow running in our mono-repo instead (either doing the update directly or triggering a workflow on the other repo).
Another (manual) solution would be to add a workflow_dispatch trigger on the workflow to allow the async-aws maintainers to trigger a run manually in case it was suspended, to restart the process (making sure that all async-aws maintainers have access to the async-aws-pr organization as well to be able to trigger it)
Those badges are meant to be updated by the logic in https://github.com/Async-AWS-PR/commits-since-release-counter
However, scheduled workflows in GitHub Actions have a rule: they disable themselves if the repository has no activity in 60 days (they don't want to spend their resources for inactive repos, which is understandable for things they provide for free). As this repo is updated only when badges are updated, it means that the infrastructure breaks if we have 60 days without activity in the mono-repo.
A solution might be to have this update be triggered by a workflow running in our mono-repo instead (either doing the update directly or triggering a workflow on the other repo).
Another (manual) solution would be to add a
workflow_dispatchtrigger on the workflow to allow the async-aws maintainers to trigger a run manually in case it was suspended, to restart the process (making sure that all async-aws maintainers have access to the async-aws-pr organization as well to be able to trigger it)