mirror of
https://github.com/RayLabsHQ/gitea-mirror.git
synced 2026-11-03 15:52:23 +01:00
[Feature suggestion] - Disable auto-sync by default #143
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/gitea-mirror#143
Reference in new issue
Block a user
Hi,
I love this app and use it everyday. It would be nice with a function to disable auto-sync by default, and then hand-pick which one I want gm to periodically sync, and even there it would be nice to add a guardrail with "approve/deny" on it.
Right now gm tries to sync everything, and it randomly picks apps that I need to hit "approve/deny" on, and about 80% of the rest is auto synced anyway, even when I added the "approve/deny" guardrail to them.
And therefore it happens every so often that gm duplcates sync entries and I end up with many duplicates that are stuck in loop and i have to manually delete them from gitea.
This is because gm tries to autosync everything at once, but a more granular control would be perfect to counter battle this
@Ratasan64 Thanks, glad you're finding it useful.
A few things to unpack here:
Per-repo auto sync control is a fair ask. Right now the scheduler syncs every repo it tracks and there's no way to opt individual repos out. I'm thinking of adding a per-repo sync policy (auto vs manual only), plus a global default so new repos can start as manual. Manual only would mean the repo never gets picked up by the scheduler and you sync it yourself when you want, which effectively gives you the approve/deny flow you're describing.
On the approve/deny behavior you're seeing: that's actually force-push protection, not a per-repo setting. It's a single global option (block on force push), and a repo only lands in pending approval when a force push is detected on it. So it's not random, and it can't currently be attached to specific repos. Clearly that wasn't obvious from the UI, which is useful feedback on its own.
The duplicates getting stuck in a loop sounds like a bug, not a settings problem. Could you open a separate issue for that with your version, what exactly gets duplicated (repos, issues, or sync jobs), and some logs if you have them? There have been fixes around duplicate detection recently so it may already be resolved on latest, but I'd like to confirm.
Ah that's great to know.
I would love to post logs, but since I posted this, I have done extensive restructure. One of them was the fact that I had a sqlite3 instance running on NFS mount, which I found out to be very bad practice, and extremely, extremely slow.
I migrated to postgres running on the server nvme disk, which is much quicker. I had also updated to the latest version the same day I posted, so I hadn't had enough time to test your new gm version thouroghly.
I will keep a keen eye on it and see, but so far so good.
Good to know. SQLite on NFS would explain a lot, file locking doesn't work reliably over NFS and that can easily cause the kind of duplicate/stuck jobs you were seeing. So the duplicates may well have been the storage setup rather than gm itself.
One thing to clarify: gitea-mirror only supports SQLite for its own database, so I assume the Postgres migration was for your Gitea instance. If you somehow moved gm's database to Postgres, let me know, that's not a supported setup.
I'll keep this issue open for the per-repo sync option. If the duplicates show up again on the new setup, open a new issue with logs and I'll take a look.
Yes, confirming it's the gitea database, not gm.
Been syncing a few thing since yesterday, and so far so good
@Ratasan64 closing this issue. Feel free to reopen it if anything was not addressed.