From acd087076cf87c0405dee0422cda5741b643b849 Mon Sep 17 00:00:00 2001
From: Lars Bilke <lars.bilke@ufz.de>
Date: Mon, 26 Feb 2018 14:49:17 +0100
Subject: [PATCH] [web] Misc. fixes in devguide section.
---
.../continuous-integration.pandoc | 6 +++---
.../docs/devguide/testing/jenkins.pandoc | 21 ++++++++++++++++++-
.../docs/devguide/testing/test-data.pandoc | 2 +-
3 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/web/content/docs/devguide/development-workflows/continuous-integration.pandoc b/web/content/docs/devguide/development-workflows/continuous-integration.pandoc
index 6fbc0881ad2..4884b8780e1 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 37246882049..84c05e89f99 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
-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 ee0894065ed..75f3e341824 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.
--
GitLab