[web] Added GitLab CI page, removed Jenkins page.

web/content/docs/devguide/development-workflows/branching-model.pandoc

@@ -32,6 +32,6 @@ You always **fetch** changes from official repository (called **upstream**), dev
 
 First thing to do when you start working on your local repository is to create a topic branch (based on the current master branch of the official repository) specific to a well defined feature or bugfix you are about to implement. **Never** work on the **master**-branch (it is reserved for the official version)! See also [this tutorial](https://www.atlassian.com/git/tutorials/using-branches) on branching.
 
-Start committing changes in logical chunks. After you are happy with your implementation push your topic branch to your forked repository on GitHub.
+Start committing changes in logical chunks. After you are happy with your implementation push your topic branch to your forked repository on GitLab.
 
 Open a *Pull Request* which will initiate the code review process.

web/content/docs/devguide/development-workflows/continuous-integration.pandoc

@@ -19,17 +19,14 @@ So for every proposed change to the source code the following is done automatica
 - A comprehensive [test suite]({{< ref "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]({{< ref "jenkins.pandoc" >}}) 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 [GitLab CI]({{< ref "gitlab-ci.pandoc" >}}) as our CI system.
 
 ## CI on OGS
 
-All of this automatically kicks in when you open a [Pull Request](../code-reviews) on GitHub. You will notice a checks block at the end of the pull request page:
+All of this automatically kicks in when you open a [Merge Request](../code-reviews) on GitLab. You will notice a pipeline block at the merge request page:
 
-![](../GH_CI_screenshot.png)
+![](../GL_CI_screenshot.png)
 
-Click on the *Details* link to find out the reason for a failed check. If you add more commits to this pull request all checks are run again.
-
-# 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. See the page on [Jenkins]({{< ref "jenkins.pandoc#automatic-testing-for-own-repository" >}}) for further information.
+Click on the pipeline link or the individual pipeline stage icons (circles) to find out the reason for a failed check. If you add more commits to this merge request all checks are run again.
 
+See the [GitLab CI page]({{< ref "gitlab-ci.pandoc" >}}) for more info.

web/content/docs/devguide/testing/gitlab-ci.pandoc

++++
+date = "2018-02-26T11:00:13+01:00"
+title = "GitLab CI"
+author = "Lars Bilke"
+weight = 1022
+
+[menu]
+  [menu.devguide]
+    parent = "testing"
++++
+
+## Introduction
+
+[GitLab CI](https://docs.gitlab.com/ee/ci/) is a powerful [Continuous Integration](../../development-workflows/continuous-integration) system integrated into GitLab.
+
+The tasks of the CI system are configured in [scripts inside the OGS source code](https://gitlab.opengeosys.org/ogs/ogs/-/tree/gitlab-ci/scripts/ci). The entrypoint is defined in [.gitlab-ci.yml](https://gitlab.opengeosys.org/ogs/ogs/-/blob/gitlab-ci/.gitlab-ci.yml). Scripting and versioning the configuration together with the source code is very powerful, e.g. if you introduce a new OGS CMake configuration in a pull request even the change of the CI jobs configuration or jobs environment (Docker container definition) can be part of the pull request.
+
+## GitLab Pipeline
+
+A CI run consists of a [pipeline](https://docs.gitlab.com/ee/ci/pipelines/) which contains [stages](https://docs.gitlab.com/ee/ci/yaml/#stages) which in turn contain jobs. A job runs a set of instructions (e.g. checking out the source code, building the code, testing the code) on a [runner](https://docs.gitlab.com/runner/).
+
+Each pipeline run is visualized as follows:
+
+![](../GitLab-Pipeline.png)
+
+Jobs are belong to a stage and each job will get a status (success, warnings, failure). Some jobs are optional (see the gear icon) and can be manually triggered by pressing the play button.
+
+## Automatic testing
+
+The master-branch of the the main repository as well as all pull requests on that repo are automatically tested. See [the pipelines page](https://gitlab.opengeosys.org/ogs/ogs/pipelines).
+
+### Skip automatic testing
+
+If you want to skip a pipeline run for a push add the `-o ci.skip` git push option. Example:
+
+```
+git push -o ci.skip
+```
+
+Or add add `[ci skip]` to the commit message to skip the pipeline for this commit. Example:
+
+```
+git commit -m "Added feature X [ci skip]"
+```
+
+### Automatic testing for own repository
+
+TODO

web/content/docs/devguide/testing/jenkins.pandoc

-+++
-date = "2018-02-26T11:00:13+01:00"
-title = "Jenkins"
-author = "Lars Bilke"
-weight = 1022
-
-[menu]
-  [menu.devguide]
-    parent = "testing"
-+++
-
-## Introduction
-
-[Jenkins](https://jenkins.io/) is a self-hosted powerful [Continuous Integration](../../development-workflows/continuous-integration) server. Our server is available at <https://jenkins.opengeosys.org>.
-
-To configure the tasks of the CI system we mainly use [Jenkins Pipeline](https://jenkins.io/doc/pipeline) jobs which are defined in a [script inside the OGS source code](https://github.com/ufz/ogs/tree/master/Jenkinsfile). Scripting and versioning the configuration together with the source code is very powerful, e.g. if you introduce a new OGS CMake configuration in a pull request even the change of the CI jobs configuration can be part of the pull request.
-
-## Jenkins Pipeline
-
-In the [Jenkinsfile](https://github.com/ufz/ogs/tree/master/Jenkinsfile) you can see lots of `stage`-blocks. Each stage is a test sub-job running on different test nodes. Inside each stage there are `steps` doing things such as configuring the build with CMake and building specific targets:
-
-```java
-stage('Win') {
-  agent {label 'win && conan' }  // Runs on a Windows node with Conan installed
-  environment {
-    MSVC_VERSION = '2017'        // Sets Visual Studio version
-  }
-  steps {
-    script {
-      configure {                // Runs CMake with options
-        cmakeOptions = '-DOGS_USE_CONAN=ON '
-      }
-      build { }                  // Builds the project
-      build { target="tests" }   // Runs unit tests
-      build { target="ctest" }   // Runs benchmark tests
-    }
-  }
-}
-```
-
-Functions such as `configure` and `build` are defined in a separate [Pipeline library](https://github.com/ufz/jenkins-pipeline-library).
-
-Each pipeline run is visualized as follows:
-
-![](../Jenkins-Pipeline.png)
-
-The status of all stages are shown. You can select one stage (e.g. *Win*) and you will see all steps inside that stage at the bottom list. You can expand the log output of a specific step by clicking the small arrow on the left.
-
-On the *Artefacts*-tab in the top navigation bar are links to the compiled binaries and generated websites (*Doxygen* code documentation and the *Web* site containing also the benchmark documentation).
-
-All of this is part of the modern Jenkins UI called *Blue Ocean*. You can always switch to the classic more comprehensive UI by clicking the arrow inside square button in the top navigation bar.
-
-## Automatic testing
-
-The master-branch of the the UFZ repository as well as all pull requests on that repo are automatically tested. See [this page](https://jenkins.opengeosys.org/blue/organizations/jenkins/ufz%2Fogs/pr) for all currently tested PRs:
-
-![](../Jenkins-PR-Overview.png)
-
-### Skip automatic testing
-
-If you want to skip the Jenkins automatic testing for a specific commit add `[ci skip]` to the commit message. This marks the Jenkins build as not built (shown as a grey icon). Example:
-
-```
-git commit -m "Added feature X [ci skip]"
-```
-
-### 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**