diff --git a/web/content/docs/devguide/development-workflows/continuous-integration.pandoc b/web/content/docs/devguide/development-workflows/continuous-integration.pandoc
index 6fbc0881ad23746ed2198fc907e1e9dbdffab7e5..4884b8780e1978405339a25b2c82f2ce13f095e5 100644
--- a/web/content/docs/devguide/development-workflows/continuous-integration.pandoc
+++ b/web/content/docs/devguide/development-workflows/continuous-integration.pandoc
@@ -16,10 +16,10 @@ weight = 1013
 So for every proposed change to the source code the following is done automatically:
 
 - Compilation of the changed code merged with the official source code is tested on a variety of platforms (Windows, Linux, Mac OS, different compilers)
-- A comprehensive [test suite](TODO: link unit testing) checks validity of the proposed changes
+- A comprehensive [test suite]({{< relref "unit-testing.pandoc" >}}) checks validity of the proposed changes
 - Additional checks regarding code formatting and documentation help in maintaining a good software quality and structure
 
-After the system is done with all these tasks the developer can view build reports highlighting occurred errors and problems. We are using [Jenkins](TODO: link) as our CI system.
+After the system is done with all these tasks the developer can view build reports highlighting occurred errors and problems. We are using [Jenkins]({{< relref "jenkins.pandoc" >}}) as our CI system.
 
 ## CI on OGS
 
@@ -31,5 +31,5 @@ Click on the *Details* link to find out the reason for a failed check. If you ad
 
 # Enable CI on your fork
 
-You can have the CI system testing all your branches in your fork of OGS even before creating a pull request. Just contact us and provide your GitHub user name.
+You can have the CI system testing all your branches in your fork of OGS even before creating a pull request. See the page on [Jenkins]({{< relref "jenkins.pandoc#automatic-testing-for-own-repository" >}}) for further information.
 
diff --git a/web/content/docs/devguide/testing/jenkins.pandoc b/web/content/docs/devguide/testing/jenkins.pandoc
index 3724688204965a3a27388edb48f267a388667c87..84c05e89f990fde98ed572fe80a1a4e1f1a39fb9 100644
--- a/web/content/docs/devguide/testing/jenkins.pandoc
+++ b/web/content/docs/devguide/testing/jenkins.pandoc
@@ -56,4 +56,23 @@ The master-branch of the the UFZ repository as well as all pull requests on that
 
 ![](../Jenkins-PR-Overview.png)
 
-Automatic testing can be easily setup for all your branches on your clone of OGS. See [the Continuous Integration page](../../getting-started/continuous-integration) for the procedure.
+### Automatic testing for own repository
+
+This assumes you have your own clone/fork of OGS on GitHub.
+
+- Tell me your GitHub user name
+- I setup a *multibranch* project on Jenkins
+ 
+This project will test all branches ending with `_j` on your repository and will be available at `jenkins.opengeosys.org/job/User/job/[your account name]`
+
+To automatically trigger new Jenkins builds when you push changes to your repository you have to setup a GitHub trigger:
+
+- Go to `github.com/[your account name]/ogs/settings/hooks`
+- Click **Add webhook**
+- Under **Payload URL** enter `https://jenkins.opengeosys.org/github-webhook/`
+- Click green button **Add webhook**
+
+To optionally let Jenkins set the result of job as the the commit status (small icons on commit list view):
+
+- Go to `github.com/[your account name]/ogs/settings/collaboration`
+- Type in `ogsbot` and click **Add collaborator**
diff --git a/web/content/docs/devguide/testing/test-data.pandoc b/web/content/docs/devguide/testing/test-data.pandoc
index ee0894065ed1a2ae93d575b2db362ba0925a4597..75f3e3418247d6919183abfd00a5ff4c4b681424 100644
--- a/web/content/docs/devguide/testing/test-data.pandoc
+++ b/web/content/docs/devguide/testing/test-data.pandoc
@@ -37,6 +37,6 @@ In the OGS-cli outputting to `[build-dir]/Tests/Data` is already handled (via th
 
 In code `BaseLib::BuildInfo::data_path` (from `BuildInfo.h`) references the data source directory and `BaseLib::BuildInfo::data_binary_path` references the data output directory.
 
-For adding new data files make sure you have [setup git lfs](../../getting-started/prerequisites) already. Then simply commit the new files as usual. For pushing you need to have [setup an account](TODO: Gitlab link) on our own GitLab server as the lfs files are stored there (due to bandwidth limitations on GitHub). When asked for GitLab credentials on pushing use your GitLab account name (should be the same as the GitHub account name) and your created GitLab personal access token ([see the GitLab Setup page](TODO: Gitlab link)).
+For adding new data files make sure you have [setup git lfs](../../getting-started/prerequisites) already. Then simply commit the new files as usual. For pushing you need to have [setup an account]({{< relref "gitlab.pandoc" >}}) on our own GitLab server as the lfs files are stored there (due to bandwidth limitations on GitHub). When asked for GitLab credentials on pushing use your GitLab account name (should be the same as the GitHub account name) and your created GitLab personal access token ([see the GitLab Setup page]({{< relref "gitlab.pandoc" >}})).
 
 Check this [in-depth tutorial](https://www.atlassian.com/git/tutorials/git-lfs) to learn more about git lfs.