mirror of
https://github.com/RayLabsHQ/gitea-mirror.git
synced 2026-04-24 23:05:53 +03:00
[GH-ISSUE #72] Automatic Mirroring and some docker compose flags not working #37
Labels
No labels
bug
documentation
enhancement
help wanted
pull-request
question
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/gitea-mirror#37
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Tailscale-VPS on GitHub (Aug 10, 2025).
Original GitHub issue: https://github.com/RayLabsHQ/gitea-mirror/issues/72
Originally assigned to: @arunavo4 on GitHub.
My Docker compose
Env Variables probably related to issue
ISSUES
1 - The GITEA_MIRROR_INTERVAL=8h counts time from the container startup OR from the time the repo was mirrored? Because as you can see i have mirrored the repos at August 9, 2025 at 11:00 PM and the container was restarted at August 10, 2025 at 04:00 AM. Till now there was no logs of mirroring again.Even when -SCHEDULE_INTERVAL=3600
Reason - Probably because of ?
- SCHEDULE_UPDATE_INTERVAL=86400000
- SCHEDULE_SKIP_RECENTLY_MIRRORED=true
- SCHEDULE_RECENT_THRESHOLD=3600000
2 - I have removed star from the winlator repo yesterday but its still not deleted from gite/gitea-mirror. Even though these flags are there
- CLEANUP_DELETE_FROM_GITEA=true
- CLEANUP_DELETE_IF_NOT_IN_GITHUB=true
- CLEANUP_ORPHANED_REPO_ACTION=archive
- CLEANUP_DRY_RUN=false
Reason - Same as for 1
After Solving the above, I believe you can aslo close https://github.com/RayLabsHQ/gitea-mirror/issues/50
@Tailscale-VPS commented on GitHub (Aug 11, 2025):
UPDATE
It's been more than 24hr's that repo's was clonned and winlator was removed from starred from github, Still no automatic mirror/delete ran after that.
So it's probably not the flags
Container restarts at 4.00 AM IST
LOGS AFTER RESTART TILL NOW
gitea-mirror-backend-2025-08-11T12-04-47.log
@arunavo4 commented on GitHub (Aug 12, 2025):
@Tailscale-VPS Thank you for the detailed logs and info. I will test and fix this today.
@arunavo4 commented on GitHub (Aug 28, 2025):
@Tailscale-VPS Have a look at v3.3.0
@Tailscale-VPS commented on GitHub (Aug 28, 2025):
Sure ill test in within 24hrs.
@Tailscale-VPS commented on GitHub (Aug 29, 2025):
@arunavo4 Here are the new findings
Docker compose ENV used -
The sync is running at every 5min which is correct but then update interval value which it should also take 5min is not working correctly .
It's automatically taking/changing it as 24 hr. (Probably because visitiing the UI changes the value and UI variable value is > value set in compose ENV varibale)
Even if i set it to 1hr from the ui , It's functioning is not correct -
It's counting the time from the last sync happened for eg is last sync is at 4.00 PM then update should be at 5.00 PM but a bit later last sync will be at 4.05 PM then the update is also changig to 5.05 PM.
Considering the above the update will never happen until sync interval is > update interval.
I have tried removing satrred repo from github , but i dont know will it be removed from the mirror when the sync runs or when the update runs.
If its deleted when the sync runs then its not working.
If its when the update runs , then ill wait cuz the update part is a bit broken currently.
Questions/Suggestion
I beleive your are checking for the repos user have forked,starred,etc in its github and matching them to mirror when the update runs?
If thats right the will it also pick up new starred,forked repos automatically when it runs update?
If YES, then i will like to point out that when new repos are found (tested from clean setup and clicking on import from github) and if sync happens, then it will do noting because they are not mirrored yet, I don't know if itts a bug or not yet implemented.
IN SHORT USER HAVE TO CLICK MIRROR FOR EVERY NEW REPO SO THAT MIRROR FUNCTION CORRECTLY
It's a minor thing but if say the above is not a bug and u were going to implemet it correctly then i would suggest to add a variable for Import from github also , currently even after setting up everything as ENV in compose , the user still needs to click on Import from github else repos will not come.
Ideally what should have happenned -
After initial setup,user should just need to do things with its github only, like fork,star new repos or remove old repos from starred.
In backend gitea mirror should do rest of the work like importing github repos and sync to gitea using compose parameters.
Log snippet if required -
@arunavo4 commented on GitHub (Aug 29, 2025):
@Tailscale-VPS Looking into it, also what is the screen resolution of this android tablet I am guessing?. I want to optimse the UI better.
@Tailscale-VPS commented on GitHub (Aug 29, 2025):
Yes its a Tab
Aspect Ratio - 7:5
Resolution- 3000 x 2120 (303 PPI)
@arunavo4 commented on GitHub (Aug 29, 2025):
@Tailscale-VPS Try v3.5.0 I have updated the UI and also your automation stuff, taken all your suggestions.
@Tailscale-VPS commented on GitHub (Aug 29, 2025):
@arunavo4 checked v3.5.0 UI looks good and here is what i have found -
The Auto import is working as expected (Even tested 2-3 times again and again, it works fine for initial setup and also when the schedular runs)
Auto mirroring still not works , So repos are stuck to imported only.
Schedular logic seems to work fine now (Also in logs u can see it tries to delete the winlator repo when schedular runs so i believe the delete functionality is also working fine, ignore the errors those are there because there was no repo named winlator in gitea as it was not mirrored)
Talking about the Scheduling time,It's not working correctly.It still has same issue and i think i found out why it's behaving this way.
What is happenning
After the initial setup using compose variables it will work fine as long as the user has not visited the configuration page from the UI.
What happens is as u are using UI values preference > Compose ENV, and you have also defined default vaules for sync and database cleanup in UI (Daily and Weekly).
The compose Env is getting overidden when the user visits the UI configuration page (You can see in log2 or in the Screenshots)
Why does this not happen earlier
The reason is simple, because other settings were blank and there were no default prefilled values, and after taking the compose env values , The UI values becomes = Compose ENV values , so no issue happens.
Suggestion
We can either remove default value from the Automation part of the UI OR we need to put a custom option there so that default value = Custom ,
And the custom value either user can put through UI or it will be filled directly through compose ENV like rest of the values.
gitea-mirror-backend-2025-08-29T17-46-11.log
gitea-mirror-backend-2025-08-29T17-57-23.log
@arunavo4 commented on GitHub (Aug 29, 2025):
@Tailscale-VPS thanks for the detailed info. Btw there is no automatic mirroring at the start. You need to first mirror the repos and only then automatic mirroring starts. Okay maybe now I understand the confusion I should change it to automatic syncing sorry for wording it wrong.
But you need to first start the mirroring manually using either mirror all button or mirroring them one by one. The reason this is done so that people who don't want to mirror certain repos can skip repos and do all that so that automatic syncing can start.
@arunavo4 commented on GitHub (Aug 29, 2025):
@Tailscale-VPS v3.5.1
@Tailscale-VPS commented on GitHub (Aug 29, 2025):
@Tailscale-VPS commented on GitHub (Aug 29, 2025):
I understand your logic, but as now most of stuff is automated and we have ignore repos also, And considering the nature of the tool isint auto mirroring should be an option ? Like we have for auto import.
And for the people who don't want to mirror certain repos they can always set the value to false or we can choose the default value to be false.
@arunavo4 commented on GitHub (Aug 30, 2025):
So you are saying you don't want to use the mirror all button from the UI rather setup everything in ENV variables and then it all starts mirroring and syncing directly right? Like how it's auto importing if you have the env variables setup
@Tailscale-VPS commented on GitHub (Aug 30, 2025):
Something similar.
We can keep the mirror button and its functionality as it is but can also add an ENV similar to
Like
Why is it false by default and why keep mirror button if using ENV
It's will be false by default because as u said there are some people who don't want to mirror certain repos.
This way those who want full automation can enable it and those who want only specific repos to be mirrored, they dont need to do anything as its disabled by default , they will keep using thte mirror button same as always.
@arunavo4 commented on GitHub (Aug 30, 2025):
@Tailscale-VPS Thanks will add this.
@arunavo4 commented on GitHub (Sep 7, 2025):
@Tailscale-VPS v3.5.3
@Tailscale-VPS commented on GitHub (Sep 7, 2025):
@arunavo4 Tested v3.5.3 -
User created container > Every Repo is Imported > Imported Repos are automatically mirrored on next sync
From what i tested it's working till step 2, i have set the sync interval for 5min to test and waited for about 20 mins seeing multiple logs about the interval passing, but the Imported repos were not mirrored,
But when i restarted the container the Imported repos were automatically started mirroring.
@arunavo4 commented on GitHub (Sep 14, 2025):
@Tailscale-VPS can you try
v3.7.2the parsing for schedule should work now andAUTO_MIRROR_REPOSenv var has been added@Tailscale-VPS commented on GitHub (Sep 14, 2025):
@arunavo4 Tested v3.7.2
Some new things
Because its not archiving the repos, they are still on mirrored state even after deleting the repo from github and removing star from another repo.
I believe it's forcing dry run... Even though i'm using dry run = false (it was working previously)
But now it's counted from the last run + when the container started.
I believe it will cause issues for people using time interval like 10m,15m,etc, though i believe people using cron will be fine.
Example
Let's assume its 12:00 AM and i want to run schedule at 6:00 AM so i have used variable value 6h,
But i have an automatic server backup which will run at 4:00 AM Daily ,
Now what happens is when the container comes up online again (lets say 4:30 AM),
Contradictions
@arunavo4 commented on GitHub (Oct 22, 2025):
@Tailscale-VPS please try out v3.8.6 addressing the dry run issue
@arunavo4 commented on GitHub (Oct 22, 2025):
Closing this for now feel free to re open if anything is pending