We recommend you use it with at least GitLab Enterprise Edition 10.0 for
> We recommend you use it with at least GitLab Enterprise Edition 10.0 for
basic Geo features, or latest version for a better experience
> basic Geo features, or latest version for a better experience
- You should make sure that all nodes run the same GitLab version
> - You should make sure that all nodes run the same GitLab version
- Geo requires PostgreSQL 9.6 and Git 2.9 in addition to GitLab's usual
> - Geo requires PostgreSQL 9.6 and Git 2.9 in addition to GitLab's usual
[minimum requirements][install-requirements]
> [minimum requirements][install-requirements]
- Using Geo in combination with High Availability (HA) is considered **Generally Available** (GA) in GitLab Enterprise Edition 10.4
> - Using Geo in combination with High Availability (HA) is considered **Generally Available** (GA) in GitLab Enterprise Edition 10.4
>
>**Note:**
>**Note:**
Geo changes significantly from release to release. Upgrades **are**
> Geo changes significantly from release to release. Upgrades **are**
supported and [documented](#updating-the-geo-nodes), but you should ensure that
> supported and [documented](#updating-the-geo-nodes), but you should ensure that
you're following the right version of the documentation for your installation!
> you're following the right version of the documentation for your installation!
The best way to do this is to follow the documentation from the `/help` endpoint
> The best way to do this is to follow the documentation from the `/help` endpoint
on your **primary** node, but you can also navigate to [this page on GitLab.com](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/doc/gitlab-geo/README.md)
> on your **primary** node, but you can also navigate to [this page on GitLab.com](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/doc/gitlab-geo/README.md)
and choose the appropriate release from the `tags` dropdown, e.g., `v10.0.0-ee`.
> and choose the appropriate release from the `tags` dropdown, e.g., `v10.0.0-ee`.
Geo allows you to replicate your GitLab instance to other geographical
Geo allows you to replicate your GitLab instance to other geographical
locations as a read-only fully operational version.
locations as a read-only fully operational version.
...
@@ -202,9 +202,8 @@ Read how to [replicate the Container Registry][docker-registry].
...
@@ -202,9 +202,8 @@ Read how to [replicate the Container Registry][docker-registry].
extra limitations may be in place.
extra limitations may be in place.
- Pushing code to a secondary redirects the request to the primary instead of handling it directly [gitlab-ee#1381](https://gitlab.com/gitlab-org/gitlab-ee/issues/1381):
- Pushing code to a secondary redirects the request to the primary instead of handling it directly [gitlab-ee#1381](https://gitlab.com/gitlab-org/gitlab-ee/issues/1381):
* Only push via HTTP is currently supported
* Push via HTTP and SSH supported
* Git LFS is supported
* Git LFS also supported
* Pushing via SSH is currently not supported: [gitlab-ee#5387](https://gitlab.com/gitlab-org/gitlab-ee/issues/5387)
- The primary node has to be online for OAuth login to happen (existing sessions and Git are not affected)
- The primary node has to be online for OAuth login to happen (existing sessions and Git are not affected)
- The installation takes multiple manual steps that together can take about an hour depending on circumstances; we are
- The installation takes multiple manual steps that together can take about an hour depending on circumstances; we are
working on improving this experience, see [gitlab-org/omnibus-gitlab#2978] for details.
working on improving this experience, see [gitlab-org/omnibus-gitlab#2978] for details.
> **Note:** It is best to set the `uid` and `gid`s prior to the initial reconfigure of GitLab. Omnibus will not recursively `chown` directories if set after the initial reconfigure.
> **Note:** It is best to set the `uid` and `gid`s prior to the initial reconfigure of GitLab. Omnibus will not recursively `chown` directories if set after the initial reconfigure.
@@ -22,39 +22,40 @@ See our [HA documentation for PostgreSQL](database.md) for information on runnin
...
@@ -22,39 +22,40 @@ See our [HA documentation for PostgreSQL](database.md) for information on runnin
1. Generate SQL_USER_PASSWORD_HASH with the command `gitlab-ctl pg-password-md5 gitlab`. We'll also need to enter the plaintext SQL_USER_PASSWORD later
1. Generate SQL_USER_PASSWORD_HASH with the command `gitlab-ctl pg-password-md5 gitlab`. We'll also need to enter the plaintext SQL_USER_PASSWORD later
1. On your database node, ensure the following is set in your `/etc/gitlab/gitlab.rb`
1. On your database node, ensure the following is set in your `/etc/gitlab/gitlab.rb`
> * [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/4466) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.6.
> * [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/4466) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.6.
>
> * ChatOps is currently in alpha, with some important features missing like access control.
> * ChatOps is currently in alpha, with some important features missing like access control.
GitLab ChatOps provides a method to interact with CI/CD jobs through chat services like Slack. Many organizations' discussion, collaboration, and troubleshooting is taking place in chat services these days, and having a method to run CI/CD jobs with output posted back to the channel can significantly augment a team's workflow.
GitLab ChatOps provides a method to interact with CI/CD jobs through chat services like Slack. Many organizations' discussion, collaboration, and troubleshooting is taking place in chat services these days, and having a method to run CI/CD jobs with output posted back to the channel can significantly augment a team's workflow.
@@ -9,7 +9,7 @@ you may need to enable pipeline triggering in your project's
...
@@ -9,7 +9,7 @@ you may need to enable pipeline triggering in your project's
## Pipelines
## Pipelines
A pipeline is a group of [jobs][] that get executed in [stages][](batches).
A pipeline is a group of [jobs] that get executed in [stages].
All of the jobs in a stage are executed in parallel (if there are enough
All of the jobs in a stage are executed in parallel (if there are enough
concurrent [Runners]), and if they all succeed, the pipeline moves on to the
concurrent [Runners]), and if they all succeed, the pipeline moves on to the
next stage. If one of the jobs fails, the next stage is not (usually)
next stage. If one of the jobs fails, the next stage is not (usually)
...
@@ -29,17 +29,17 @@ There are three types of pipelines that often use the single shorthand of "pipel
...
@@ -29,17 +29,17 @@ There are three types of pipelines that often use the single shorthand of "pipel
![Types of Pipelines](img/types-of-pipelines.svg)
![Types of Pipelines](img/types-of-pipelines.svg)
1.**CI Pipeline**: Build and test stages defined in `.gitlab-ci.yml`
1.**CI Pipeline**: Build and test stages defined in `.gitlab-ci.yml`.
2.**Deploy Pipeline**: Deploy stage(s) defined in `.gitlab-ci.yml` The flow of deploying code to servers through various stages: e.g. development to staging to production
1.**Deploy Pipeline**: Deploy stage(s) defined in `.gitlab-ci.yml` The flow of deploying code to servers through various stages: e.g. development to staging to production.
3.**Project Pipeline**: Cross-project CI dependencies [triggered via API][triggers], particularly for micro-services, but also for complicated build dependencies: e.g. api -> front-end, ce/ee -> omnibus.
1.**Project Pipeline**: Cross-project CI dependencies [triggered via API][triggers], particularly for micro-services, but also for complicated build dependencies: e.g. api -> front-end, ce/ee -> omnibus.
## Development workflows
## Development workflows
Pipelines accommodate several development workflows:
Pipelines accommodate several development workflows:
1.**Branch Flow** (e.g. different branch for dev, qa, staging, production)
1.**Branch Flow** (e.g. different branch for dev, qa, staging, production).
2.**Trunk-based Flow** (e.g. feature branches and single master branch, possibly with tags for releases)
1.**Trunk-based Flow** (e.g. feature branches and single master branch, possibly with tags for releases).
3.**Fork-based Flow** (e.g. merge requests come from forks)
1.**Fork-based Flow** (e.g. merge requests come from forks).
Example continuous delivery flow:
Example continuous delivery flow:
...
@@ -57,6 +57,16 @@ Pipelines are defined in `.gitlab-ci.yml` by specifying [jobs] that run in
...
@@ -57,6 +57,16 @@ Pipelines are defined in `.gitlab-ci.yml` by specifying [jobs] that run in
See the reference [documentation for jobs](yaml/README.md#jobs).
See the reference [documentation for jobs](yaml/README.md#jobs).
## Manually executing pipelines
Pipelines can be manually executed, with predefined or manually-specified [variables](variables/README.md).
To execute a pipeline manually:
1. Navigate to your project's **CI/CD > Pipelines**.
1. Click on the **Run Pipeline** button.
1. Select the branch to run the pipeline for and enter any environment variables required for the pipeline run.
## Seeing pipeline status
## Seeing pipeline status
You can find the current and historical pipeline runs under your project's
You can find the current and historical pipeline runs under your project's
...
@@ -112,9 +122,9 @@ Then, there is the pipeline mini graph which takes less space and can give you a
...
@@ -112,9 +122,9 @@ Then, there is the pipeline mini graph which takes less space and can give you a
quick glance if all jobs pass or something failed. The pipeline mini graph can
quick glance if all jobs pass or something failed. The pipeline mini graph can
be found when you visit:
be found when you visit:
-the pipelines index page
-The pipelines index page.
-a single commit page
-A single commit page.
-a merge request page
-A merge request page.
That way, you can see all related jobs for a single commit and the net result
That way, you can see all related jobs for a single commit and the net result
of each stage of your pipeline. This allows you to quickly see what failed and
of each stage of your pipeline. This allows you to quickly see what failed and
...
@@ -142,9 +152,9 @@ jobs. Click to expand them.
...
@@ -142,9 +152,9 @@ jobs. Click to expand them.
The basic requirements is that there are two numbers separated with one of
The basic requirements is that there are two numbers separated with one of
the following (you can even use them interchangeably):
the following (you can even use them interchangeably):
-a space
-A space (` `)
-a slash (`/`)
-A slash (`/`)
-a colon (`:`)
-A colon (`:`)
>**Note:**
>**Note:**
More specifically, [it uses][regexp] this regular expression: `\d+[\s:\/\\]+\d+\s*`.
More specifically, [it uses][regexp] this regular expression: `\d+[\s:\/\\]+\d+\s*`.
...
@@ -257,11 +267,12 @@ A strict security model is enforced when pipelines are executed on
...
@@ -257,11 +267,12 @@ A strict security model is enforced when pipelines are executed on
The following actions are allowed on protected branches only if the user is
The following actions are allowed on protected branches only if the user is
[allowed to merge or push](../user/project/protected_branches.md#using-the-allowed-to-merge-and-allowed-to-push-settings)
[allowed to merge or push](../user/project/protected_branches.md#using-the-allowed-to-merge-and-allowed-to-push-settings)
on that specific branch:
on that specific branch:
- run **manual pipelines** (using Web UI or Pipelines API)
- run **scheduled pipelines**
- Run **manual pipelines** (using [Web UI](#manually-executing-pipelines) or Pipelines API).
- run pipelines using **triggers**
- Run **scheduled pipelines**.
- trigger **manual actions** on existing pipelines
- Run pipelines using **triggers**.
-**retry/cancel** existing jobs (using Web UI or Pipelines API)
- Trigger **manual actions** on existing pipelines.
-**Retry/cancel** existing jobs (using Web UI or Pipelines API).
**Variables** marked as **protected** are accessible only to jobs that
**Variables** marked as **protected** are accessible only to jobs that
run on protected branches, avoiding untrusted users to get unintended access to
run on protected branches, avoiding untrusted users to get unintended access to
expect(json_response['error']).toeql('secret_token is missing, data is missing, data[gl_id] is missing, data[primary_repo] is missing, output is missing')