Stanislav N. opened 2 years ago
|
|||||
You may add a helper project, configure its build spec to run a job with a cron schedule. The job pulls from remote repository and push into local repository. I experimented mirroring a github repo and below is the example build spec:
In production, you may want to replace access token with job secret for security reason. |
|||||
Tips: To copy a build spec, edit your build spec and switch to |
|||||
Sounds like a crutch :) I think it's better to have a separate setting for repository which will contain remote repository's URL. There are two ways I saw that in the wild:
I was speaking about something like that. |
|||||
Thanks for the info. Will add the mirror concept in future version. |
|||||
This is probably the only missing feature that is keeping me from fully switching from Gitea. I self-host locally and on a Linode. I have backups of of the containers data volumes, but I like to have my two instances synchronized for redundancy that won't require a restore in a failure scenario. For instance, if the server hosting the git service fails. Another use-case is to backup repos from github/gitlab that are not my own. Basically, I mean backing up my starred repos. This might be more out of the scope of what onedev is meant for. If it was implemented though, I think I would fully move to onedev for backing up public repos and as my git server. I loved the import process from Gitea, and how it lets you do them in bulk. Gitea, for comparison, makes you import a single repo at a time. I'll try the build script above soon, but It looks time-consuming to do if you have a lot of repos. I'll share how I would like to see this implemented.
I may be thinking too much in a self-hosting mindset though. Having all of these implementations might add a lot of overhead and people hosting public instances might not want anyone/everyone to have access to this. There is also a benefit for self-hosters that it makes it easier to try onedev. There is zero risk because we could mirror our current git server until we decide to fully make the switch. :-) |
|||||
Thanks for the suggestions. For automated sync, I plan to add built-in step to support that. Then user can easily accomplish the task with current CI/CD job schedule facility. This will not make OneDev too complicated to solve different use cases. I have a question though for repository mirror: how do you proceed if both sides changed the repository, do you want a merge in this case? And in case of merge conflict, do you want to create a pull request and notify repository owner to resolve it? |
|||||
I think you pretty much hit the nail on the head. A merge conflict would be best handled with a pull request and a notification to the owner. Another thing, now that I am thinking about it. Using the CI/CD job schedule it would be best if, in addition to a cron schedule, the push/pull could be triggered whenever a change is made on either repo. Ideally, both would push to the other immediately, then merge conflicts would be pushed back into between the devices and an individual server, hopefully™. Even if this is the case you would want to do like you said above for whenever it does happen. Thanks for your prompt response, by the way. 😁 |
|||||
Robin Shen added to milestone "7.1.0" 2 years ago
|
|||||
OneDev changed state to 'Closed' 2 years ago
|
|||||
State changed as code fixing the issue is committed |
|||||
OneDev changed state to 'Released' 2 years ago
|
|||||
State changed as build #2600 is successful |
|||||
dufernst changed state to 'Open' 2 years ago
|
|||||
Thanks for the new functionality it works perfect for my own repositories (that I want to sync between OneDev and Github). However, for public repositories not controlled by me, the current approach with a configured pipeline in the repo itself, conflicts with the fast forward (and in general with creating a clean mirror of a remote repo). Your proposed syncing option in a helper repo would theoretically work, but in practice having to clone 20-30GB spread over +- 100 repositories every time syncing occurs is not sensible. A couple of options include:
|
|||||
OneDev changed state to 'Closed' 2 years ago
|
|||||
State changed as code fixing the issue is committed |
|||||
OneDev changed state to 'Released' 2 years ago
|
|||||
State changed as build #2956 is successful |
|||||
Hi, on many projects which I want to have on my local onedev instance, I’m using PullRepository step to achieve a sort of gitea “repo-mirror” feature, but in this way I’m forced to keep the default branch to the one with the relative build-spec. thank you! |
|||||
The pull repository step now has a sync child option like below: |
Hello, I want to be able to pull remote repository into a project inside 1dev e.g. from github or gitlab. Why:
Maybe there are more use cases, but these are mine.