diff options
Diffstat (limited to 'doc/integration')
| -rw-r--r-- | doc/integration/elasticsearch.md | 2 | ||||
| -rw-r--r-- | doc/integration/gmail_action_buttons_for_gitlab.md | 12 |
2 files changed, 8 insertions, 6 deletions
diff --git a/doc/integration/elasticsearch.md b/doc/integration/elasticsearch.md index 47497e7b385..48f39ea4bc9 100644 --- a/doc/integration/elasticsearch.md +++ b/doc/integration/elasticsearch.md @@ -610,7 +610,7 @@ Here are some common pitfalls and how to overcome them: - **My single node Elasticsearch cluster status never goes from `yellow` to `green` even though everything seems to be running properly** - **For a single node Elasticsearch cluster the functional cluster health status will be yellow** (will never be green) because the primary shard is allocated but replicas can not be as there is no other node to which Elasticsearch can assign a replica. This also applies if you are using using the + **For a single node Elasticsearch cluster the functional cluster health status will be yellow** (will never be green) because the primary shard is allocated but replicas can not be as there is no other node to which Elasticsearch can assign a replica. This also applies if you are using the [Amazon Elasticsearch](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-handling-errors.html#aes-handling-errors-yellow-cluster-status) service. CAUTION: **Warning**: Setting the number of replicas to `0` is not something that we recommend (this is not allowed in the GitLab Elasticsearch Integration menu). If you are planning to add more Elasticsearch nodes (for a total of more than 1 Elasticsearch) the number of replicas will need to be set to an integer value larger than `0`. Failure to do so will result in lack of redundancy (losing one node will corrupt the index). diff --git a/doc/integration/gmail_action_buttons_for_gitlab.md b/doc/integration/gmail_action_buttons_for_gitlab.md index 3c01817032b..1ab01494edc 100644 --- a/doc/integration/gmail_action_buttons_for_gitlab.md +++ b/doc/integration/gmail_action_buttons_for_gitlab.md @@ -6,16 +6,18 @@ If correctly set up, emails that require an action will be marked in Gmail.  -To get this functioning, you need to be registered with Google. -[See how to register with Google in this document.](https://developers.google.com/gmail/markup/registering-with-google) +To get this functioning, you need to be registered with Google. For instructions, see +[Register with Google](https://developers.google.com/gmail/markup/registering-with-google). *This process has a lot of steps so make sure that you fulfill all requirements set by Google.* *Your application will be rejected by Google if you fail to do so.* -Pay close attention to: +In particular, note: -- Email account used by GitLab to send notification emails needs to have "Consistent history of sending a high volume of mail from your domain (order of hundred emails a day minimum to Gmail) for a few weeks at least". -- "A very very low rate of spam complaints from users." +- The email account used by GitLab to send notification emails must: + - Have a "Consistent history of sending a high volume of mail from your domain + (order of hundred emails a day minimum to Gmail) for a few weeks at least". + - Have a very low rate of spam complaints from users. - Emails must be authenticated via DKIM or SPF. - Before sending the final form ("Gmail Schema Whitelist Request"), you must send a real email from your production server. This means that you will have to find a way to send this email from the email address you are registering. You can do this by, for example, forwarding the real email from the email address you are registering or going into the rails console on the GitLab server and triggering the email sending from there. |