Keeping Mirrors and Forks in Sync
One issue you first encounter when you first use Onedev is when you fork a repository you realise at first you are not too sure how to keep the fork or mirrors in sync with upstream.
Well you are in luck, this guide will teach you how to keep your projects in sync.
This guide is similar to Repository mirror guide, however it focuses more on syncronisation rather than creating the mirror.
Common issues
A common issue you encounter when you mirror using CI/CD tasks is that the mirrored tasks conflict the task you have created to mirror the code, there is two solutions for this, using a special branch which only contains a CI/CD task to sync the other branches, but this can get pretty messy.
In this guide we will make use of the clone into child project feature provided by Onedev.
Setup
This method of keeping projects in sync only work if the project has a parent project.
Say your username is foo
and you wanted to fork a project called
bar
, fork the repository into the group foo
so that the project path
is /foo/bar
.
foo
repository, aka your users repositories, need to have the code
management
feature enabled, but have issue management
disabled, this
project should inherit permissions from parent
, and be kept private,
it is only for syncing the child projects, which can be open sourced if
desired.
You do not need to make the foo
private, it will not reveal any
personal data, but it looks nicer within the explorer if people can not
browse a dummy project which only goal is to sync other projects.
bar
repository (which you forked from the upstream bar repository)
should have code management
enabled, but also have issue management
disabled as it is a fork, and thus people should submit issues to the
upstream project and not the fork (unless the fork is distributed
separately, then it should have its own issue management).
Once these repositories have been setup, go to the foo project, and
select setting up build spec
, see screenshot below:
Next we need to add a new job.
Next name it sync, as you can see below:
You can name the job anything you like, but naming it "sync" makes the most sense as it clearly identifies the function of the job.
Now lets add a step, in this case we only need one, a step to pull the upstream changes into the repository, see below:
We want to select pull from remote. Then we can configure this step below:
Name the step the name of the project you are syncronising, this allows you to chain multiple steps together to sync multiple child projects at once.
The remote url
should be the http url of the project you forked, or
mirrored, which you would like to keep in sync with.
Now the most important part, enable Sync to child project
and then
select the child project you would like to sync the repository into, in
this case it is bar
.
Scroll down as there is still a few settings to change:
If you have synced or mirrored a private repository, you will need to
fill in the Username
and Password
field with a user which has
permission to READ the source code within the repository you are
keeping in sync with.
Enable Transfer Git LFS Files
if the repository you are staying in
sync with uses git-lfs.
If you are not sure whether the project you are staying in sync with uses git-lfs, enabling the option even if it is never used is better than not enabling it and missing files.
Finally we want to set Condition
to always
, this allows us to add
other steps later on to sync additional child projects with their
upstreams, thus you only need one job to keep all of your projects in
sync.
Congratulations, you have created the job, click ok
.
We now need to save the configuration:
Click save, and then:
Commit the changes to the repository.
There, the entire process of setting up the sync is done.
Syncing your projects
After you have completed the setup, syncing your projects is as simple as executing the sync build:
Click the start button and a build will be started, this build will sync all the data from the upstream repository into the child project you have defined.
After the build finishes, you should be able to enter your project, in
our case this is bar
and see all the code syncronised.
Congratulations, good luck contributing on other projects now that you can keep your forks in sync with upstream!