[Feature Request] - Custom Automatic Sync Schedules per Repository #182

New Issue

2026-10-27T12:09:46+01:00

adam commented

2026-10-27 12:09:46 +01:00

Hi,

I've touched briefly on having individual sync toggles for each repository, and that remains a feature I'd love to see. That said, I think it would also be valuable to have granular control over when each sync executes.

After using Gitea Mirror extensively, I've noticed that running multiple mirroring workers simultaneously can corrupt Gitea repositories. This has happened frequently enough that I've ended up deleting the affected repositories from both Gitea and Gitea Mirror, then re-adding and re-syncing them entirely to resolve the issues caused by sync overload. This is not necessarily a Gitea Mirror issue, but could be NFS-issue or other I/O overload reasons.

As an example, I maintain 10–20 repositories that need to stay up to date out of a larger set. Being able to selectively enable sync for just those 20... and schedule them at staggered intervals (e.g., App1 at 1:00 AM, App2 at 1:10 AM, and so on), would go a long way toward preventing these conflicts.

Would implementing this be straightforward? Having the ability to leave most repos untouched and focus only on the critical ones, spaced throughout the night, would be a meaningful improvement.

Hi, I've touched briefly on having individual sync toggles for each repository, and that remains a feature I'd love to see. That said, I think it would also be valuable to have granular control over when each sync executes. After using Gitea Mirror extensively, I've noticed that running multiple mirroring workers simultaneously can corrupt Gitea repositories. This has happened frequently enough that I've ended up deleting the affected repositories from both Gitea and Gitea Mirror, then re-adding and re-syncing them entirely to resolve the issues caused by sync overload. This is not necessarily a Gitea Mirror issue, but could be NFS-issue or other I/O overload reasons. As an example, I maintain 10–20 repositories that need to stay up to date out of a larger set. Being able to selectively enable sync for just those 20... and schedule them at staggered intervals (e.g., App1 at 1:00 AM, App2 at 1:10 AM, and so on), would go a long way toward preventing these conflicts. Would implementing this be straightforward? Having the ability to leave most repos untouched and focus only on the critical ones, spaced throughout the night, would be a meaningful improvement.

adam commented

2026-10-27 12:09:47 +01:00

@CipherVortex5 Thanks for the details. Some context first: when gitea-mirror syncs a repo, it only asks Gitea to queue the pull. Gitea runs those pulls, plus its own scheduled ones, in parallel. By default it uses up to half the CPU count as workers (between 1 and 10). That count can be higher than a container's CPU limit.

To have Gitea run one pull at a time, add this to Gitea's app.ini:

[queue.mirror]
MAX_WORKERS = 1

This lowers the load but may not stop the corruption. Pulls of different repos write to different directories, so running them in parallel shouldn't corrupt anything by itself, and git on NFS can have problems even with one pull at a time. If it keeps happening, could you share:

the error you see, from git fsck or the Gitea log
whether Gitea's data directory is on NFS

@CipherVortex5 Thanks for the details. Some context first: when gitea-mirror syncs a repo, it only asks Gitea to queue the pull. Gitea runs those pulls, plus its own scheduled ones, in parallel. By default it uses up to half the CPU count as workers (between 1 and 10). That count can be higher than a container's CPU limit. To have Gitea run one pull at a time, add this to Gitea's `app.ini`: ```ini [queue.mirror] MAX_WORKERS = 1 ``` This lowers the load but may not stop the corruption. Pulls of different repos write to different directories, so running them in parallel shouldn't corrupt anything by itself, and git on NFS can have problems even with one pull at a time. If it keeps happening, could you share: - the error you see, from `git fsck` or the Gitea log - whether Gitea's data directory is on NFS

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/gitea-mirror#182