Mirror functionality broken #271

Closed
opened 2025-11-02 03:16:49 -06:00 by GiteaMirror · 6 comments
Owner

Originally created by @issmirnov on GitHub (Jan 24, 2017).

  • Gitea version (or commit ref): 1.0.1 (official release)
  • Git version: 2.7.4
  • Operating system: Ubuntu 16.04.01
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No (try.gitea is down, and I also use private repo)
    • Not relevant
  • Log gist: Not providing in case there is sensitive date. This should be easy to repro though.

Description

Hello all. It appears that sometime between the last gogs release and the latest gitea release the mirror functionality has been broken. I've noticed that none of my mirror repos have been syncing as per the 8H schedule. I can sync manually, but even after enabling and disabling sync frequencies nothing seems to have changed.

In addition, there appears to be a UI bug. When I added a second instance of my mirror repo, it gets put in the list of Repositories rather than Mirrors.

Repro

I created a test account on try.gitea.io, username test33 and password test33. I set up a mirror of my dotfiles repo. Right now https://try.gitea.io is returning a 404, so I am unable co confirm. However, is someone can set up a mirror on their instance and see if they encounter the two issues (not syncing, and wrong UI) then we can get to the bottom of this.

I will try to find time later this week to set up a second instance and see if mirrors are broken on a clean install. Perhaps the gogs -> gitea migration broke some mirror hook. To be safe, I cleared all the update hooks and updated SSH keys.

Originally created by @issmirnov on GitHub (Jan 24, 2017). - Gitea version (or commit ref): 1.0.1 (official release) - Git version: 2.7.4 - Operating system: Ubuntu 16.04.01 - Database (use `[x]`): - [ ] PostgreSQL - [X] MySQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [X] No (try.gitea is down, and I also use private repo) - [ ] Not relevant - Log gist: Not providing in case there is sensitive date. This should be easy to repro though. ## Description Hello all. It appears that sometime between the last gogs release and the latest gitea release the mirror functionality has been broken. I've noticed that none of my mirror repos have been syncing as per the 8H schedule. I can sync manually, but even after enabling and disabling sync frequencies nothing seems to have changed. In addition, there appears to be a UI bug. When I added a second instance of my mirror repo, it gets put in the list of Repositories rather than Mirrors. ## Repro I created a test account on try.gitea.io, username `test33` and password `test33`. I set up a mirror of my [dotfiles](https://github.com/issmirnov/dotfiles) repo. Right now https://try.gitea.io is returning a 404, so I am unable co confirm. However, is someone can set up a mirror on their instance and see if they encounter the two issues (not syncing, and wrong UI) then we can get to the bottom of this. I will try to find time later this week to set up a second instance and see if mirrors are broken on a clean install. Perhaps the gogs -> gitea migration broke some mirror hook. To be safe, I cleared all the update hooks and updated SSH keys.
GiteaMirror added the type/bug label 2025-11-02 03:16:49 -06:00
Author
Owner

@plessbd commented on GitHub (Jan 24, 2017):

I thought this was the case to
however you just have to enable the cron in the app.ini and the updating works.

; Update mirrors
[cron.update_mirrors]
SCHEDULE = @every 10m

; Repository health check
[cron.repo_health_check]
SCHEDULE = @every 24h
TIMEOUT = 60s
; Arguments for command 'git fsck', e.g. "--unreachable --tags"
; see more on http://git-scm.com/docs/git-fsck/1.7.5
ARGS =

[cron]
ENABLED = true
RUN_AT_START = true
@plessbd commented on GitHub (Jan 24, 2017): I thought this was the case to however you just have to enable the cron in the app.ini and the updating works. ``` ; Update mirrors [cron.update_mirrors] SCHEDULE = @every 10m ; Repository health check [cron.repo_health_check] SCHEDULE = @every 24h TIMEOUT = 60s ; Arguments for command 'git fsck', e.g. "--unreachable --tags" ; see more on http://git-scm.com/docs/git-fsck/1.7.5 ARGS = [cron] ENABLED = true RUN_AT_START = true ```
Author
Owner

@issmirnov commented on GitHub (Jan 24, 2017):

Thank you! I had no idea. Is this part of the upgrade flow? I can imagine many gogs users who are used to mirrors working who don't know about this when they migrate.

@issmirnov commented on GitHub (Jan 24, 2017): Thank you! I had no idea. Is this part of the upgrade flow? I can imagine many gogs users who are used to mirrors working who don't know about this when they migrate.
Author
Owner

@plessbd commented on GitHub (Jan 24, 2017):

I am not positive. Both of the app.ini files seem to have a "default" of enabled, so I am not positive where the disconnect happened.

@plessbd commented on GitHub (Jan 24, 2017): I am not positive. Both of the app.ini files seem to have a "default" of enabled, so I am not positive where the disconnect happened.
Author
Owner

@issmirnov commented on GitHub (Jan 25, 2017):

Sounds good. Closing for now, people can reopen if they stumble upon this issue as well. Thank you for helping with the fix.

@issmirnov commented on GitHub (Jan 25, 2017): Sounds good. Closing for now, people can reopen if they stumble upon this issue as well. Thank you for helping with the fix.
Author
Owner

@cez81 commented on GitHub (Feb 26, 2017):

I think the problem still exist. Done a clean install (1.0.0+339-g5bd22a2 + SQLite) and added a mirror. No cron jobs showing under monitoring and repo is not updated.
After adding values to custom app.ini it works. Looks like default values are not working.

@cez81 commented on GitHub (Feb 26, 2017): I think the problem still exist. Done a clean install (1.0.0+339-g5bd22a2 + SQLite) and added a mirror. No cron jobs showing under monitoring and repo is not updated. After adding values to custom app.ini it works. Looks like default values are not working.
Author
Owner

@lunny commented on GitHub (Feb 27, 2017):

Wrong default value seems is an issue.

@lunny commented on GitHub (Feb 27, 2017): Wrong default value seems is an issue.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#271