Automatic Removal of Dynamic Forgejo Runners #2173

aahlenst commented 2025年10月13日 15:33:38 +02:00

Comment

Forgejo allows to register Forgejo Runners dynamically. I use that functionality to create single-use runners on-demand in response to pending jobs that I obtain by polling /orgs/{org}/actions/runners/jobs and /orgs/{org}/actions/runners/jobs. Those runners have unique names to prevent conflicts. Forgejo offers no API to remove those runners. But I can enable the cron job Cleanup Offline Runners that removes them automatically after a configurable amount of time.

On Codeberg, I can do the same. But the stale runners pile up because Cleanup Offline Runners is not enabled.

It would be great if Codeberg could remove those stale runners automatically as well.

Simply enabling Cleanup Offline Runners might be problematic for some people. For example, I would not want my persistent runner to be removed just because it happens to be offline. Therefore, having some mechanism to opt-in on an {organization,user,repository} basis would be great. Furthermore, it would be nice if there was a possibility to mark a runner as "dynamic" which would prevent persistent runners from being removed even if automatic removal of offline runners were enabled. I'd welcome that functionality in Forgejo as well.

Alternatively, having an API for runner removal would work as well.

### Comment Forgejo allows to register Forgejo Runners dynamically. I use that functionality to create single-use runners on-demand in response to pending jobs that I obtain by polling `/orgs/{org}/actions/runners/jobs` and `/orgs/{org}/actions/runners/jobs`. Those runners have unique names to prevent conflicts. Forgejo offers no API to remove those runners. But I can enable the cron job [Cleanup Offline Runners](https://forgejo.org/docs/latest/admin/config-cheat-sheet/#cron---cleanup-offline-runners-croncleanup_offline_runners) that removes them automatically after a configurable amount of time. On Codeberg, I can do the same. But the stale runners pile up because Cleanup Offline Runners is not enabled. It would be great if Codeberg could remove those stale runners automatically as well. Simply enabling Cleanup Offline Runners might be problematic for some people. For example, I would not want my persistent runner to be removed just because it happens to be offline. Therefore, having some mechanism to opt-in on an {organization,user,repository} basis would be great. Furthermore, it would be nice if there was a possibility to mark a runner as "dynamic" which would prevent persistent runners from being removed even if automatic removal of offline runners were enabled. I'd welcome that functionality in Forgejo as well. Alternatively, having an API for runner removal would work as well.

fnetX commented 2025年10月14日 17:31:41 +02:00

I suggest to enable the cron job for Codeberg, targetting runners that are offline for at least 14 days. It will prevent unbounded growth of the list. 14 days seems like a reasonable amount to fix and reconnect persistent runners that stopped working or are not intended to be online all the time. Maybe 30 days could also work?

AFAIK "removing" a runner does not really free up resources. It is still in the database and no data is removed. The only benefit is hiding it from the list of runners.

@aahlenst Could yo elalaborate on the problem you are facing? Is the list of offline runners a problem for you? Why? In which cases do you access it? I'm rather thinking in the direction of hiding inactive runners, but still keeping them accessible. I see no need to permanently disable a runner.

I suggest to enable the cron job for Codeberg, targetting runners that are offline for at least 14 days. It will prevent unbounded growth of the list. 14 days seems like a reasonable amount to fix and reconnect persistent runners that stopped working or are not intended to be online all the time. Maybe 30 days could also work? AFAIK "removing" a runner does not really free up resources. It is still in the database and no data is removed. The only benefit is hiding it from the list of runners. @aahlenst Could yo elalaborate on the problem you are facing? Is the list of offline runners a problem for you? Why? In which cases do you access it? I'm rather thinking in the direction of hiding inactive runners, but still keeping them accessible. I see no need to permanently disable a runner.

aahlenst commented 2025年10月14日 17:56:42 +02:00

In my case, a single runner is used exactly once and never again. So there's no point in keeping them around. They only occupy resources. Having 10,000 dead runners in a single project seems wasteful.

I access the list of runners to manage persistent runners. If the list is full of stale dynamic runners, I have to use the search functionality to find them.

However, I wouldn't consider any of those issues to be a real problem, only an inconvenience.

In my case, a single runner is used exactly once and never again. So there's no point in keeping them around. They only occupy resources. Having 10,000 dead runners in a single project seems wasteful. I access the list of runners to manage persistent runners. If the list is full of stale dynamic runners, I have to use the search functionality to find them. However, I wouldn't consider any of those issues to be a real problem, only an inconvenience.

fnetX commented 2025年10月14日 18:07:16 +02:00

As I said, as far as I know there are no resources "freed" on our side by the cron job. they just manage visibility.

As I said, as far as I know there are no resources "freed" on our side by the cron job. they just manage visibility.