Matrix Feature Cleanup #153

New Issue

2026-10-05T01:45:02+02:00

adam commented

2026-10-05 01:45:02 +02:00

The parent task for Matrix Support

https://github.com/RayLabsHQ/gitea-mirror/pull/368#issuecomment-5505564286

Please ensure all PRs for the following issues are against feature/matrix so all capabilities of the matrix feature can be fully tested before merging into main

Please use this issue to discuss the matrix feature, instead of the individual sub issues, so that the discussions can stay in a central place

The parent task for Matrix Support https://github.com/RayLabsHQ/gitea-mirror/pull/368#issuecomment-5505564286 Please ensure all PRs for the following issues are against `feature/matrix` so all capabilities of the matrix feature can be fully tested before merging into `main` - [x] #391 - [x] #392 - [ ] #393 - [x] #394 - [x] #395 - [x] #396 - [x] #397 - [x] #398 - [x] #399 ### Please use this issue to discuss the matrix feature, instead of the individual sub issues, so that the discussions can stay in a central place

adam closed this issue

2026-10-05 01:45:02 +02:00

adam commented

2026-10-05 01:45:03 +02:00

@arunavo4
I should have created issues for all of the remaining features that you mentioned in my PR.

I do have a question since you mentioned you won't do bi-directional mirroring:

Would you consider bidirectional mirroring of the source only (so it can only push the source, none of the releases, issues, LFS, Releases,...?
2)) Are you planning to only have Gitea/Forgejo as the target for the sync? Or could you pull from something like codeberg, and have it sync to your local GitLab Instance?

@arunavo4 I should have created issues for all of the remaining features that you mentioned in my PR. I do have a question since you mentioned you won't do bi-directional mirroring: 1) Would you consider bidirectional mirroring of the source only (so it can only push the source, none of the releases, issues, LFS, Releases,...? 2)) Are you planning to only have Gitea/Forgejo as the target for the sync? Or could you pull from something like codeberg, and have it sync to your local GitLab Instance?

adam commented

2026-10-05 01:45:04 +02:00

Thanks for filing these. Bad timing on my side: the list you copied is from my review comment at 06:40 on Sep 2, and most of it shipped to main the same day. Sources went out in v3.30.0 (#376) at 09:29 and the push engine in v3.31.0 (#384) at 13:40, both before these issues were opened.

Main did not take the servers plus mirror_pairs model. Item 5 in the review was the reason: the pair options had duplicate fields, and migration 0015 would have frozen that shape on release day. Instead each repository row records source_provider, source_url, destination_provider and destination_url (migrations 0015 and 0018), and the mirror path picks credentials from those and refuses a row that belongs to a different host. Same capability, no join table.

Where that leaves the list:

#391 shipped in v3.30.0, one source per user for now.
#394 shipped in v3.31.0 for GitHub and GitLab targets.
#392, #395, #397, #398, #399 describe code that only exists on feature/matrix. Nothing to do on main.
#396 never applied to main, the Import button is still there.
#393, more than one target per repository, is the one piece still open.

feature/matrix will not be merged as it stands, and it cannot be rebased either: both branches carry a migration numbered 0015. I have deleted the branch. The merged tree is still reachable as 90ece41 from #368 if you need to pull anything out of it. Please open any further PRs against main.

Your two questions:

No bidirectional mirroring, source only included. Gitea Mirror pushes one way and stays a backup tool.
Targets are not Gitea only any more. As of 3.31.0 the destination can be Gitea, Forgejo, GitHub or GitLab, and the source can be GitHub, GitLab, Gitea or Forgejo (Codeberg included). All twelve pairs were run against real hosts before the release, so Codeberg to a self hosted GitLab works today.

If you want to keep going, #393 is the piece to take. Since it changes the repositories model, please sketch the approach on that issue before writing code so we agree on the shape first.

Thanks for filing these. Bad timing on my side: the list you copied is from my review comment at 06:40 on Sep 2, and most of it shipped to main the same day. Sources went out in v3.30.0 (#376) at 09:29 and the push engine in v3.31.0 (#384) at 13:40, both before these issues were opened. Main did not take the servers plus mirror_pairs model. Item 5 in the review was the reason: the pair options had duplicate fields, and migration 0015 would have frozen that shape on release day. Instead each repository row records source_provider, source_url, destination_provider and destination_url (migrations 0015 and 0018), and the mirror path picks credentials from those and refuses a row that belongs to a different host. Same capability, no join table. Where that leaves the list: - #391 shipped in v3.30.0, one source per user for now. - #394 shipped in v3.31.0 for GitHub and GitLab targets. - #392, #395, #397, #398, #399 describe code that only exists on feature/matrix. Nothing to do on main. - #396 never applied to main, the Import button is still there. - #393, more than one target per repository, is the one piece still open. feature/matrix will not be merged as it stands, and it cannot be rebased either: both branches carry a migration numbered 0015. I have deleted the branch. The merged tree is still reachable as 90ece41 from #368 if you need to pull anything out of it. Please open any further PRs against main. Your two questions: 1. No bidirectional mirroring, source only included. Gitea Mirror pushes one way and stays a backup tool. 2. Targets are not Gitea only any more. As of 3.31.0 the destination can be Gitea, Forgejo, GitHub or GitLab, and the source can be GitHub, GitLab, Gitea or Forgejo (Codeberg included). All twelve pairs were run against real hosts before the release, so Codeberg to a self hosted GitLab works today. If you want to keep going, #393 is the piece to take. Since it changes the repositories model, please sketch the approach on that issue before writing code so we agree on the shape first.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/gitea-mirror#153