diff options
Diffstat (limited to 'doc/integration')
25 files changed, 153 insertions, 71 deletions
diff --git a/doc/integration/README.md b/doc/integration/README.md index 25e8c1a51c1..acf37374c30 100644 --- a/doc/integration/README.md +++ b/doc/integration/README.md @@ -64,7 +64,7 @@ Integration with services such as Campfire, Flowdock, HipChat, Pivotal Tracker, ### SSL certificate errors -When trying to integrate GitLab with services that are using self-signed certificates, it is very likely that SSL certificate errors will occur in different parts of the application, most likely Sidekiq. +When trying to integrate GitLab with services that are using self-signed certificates, it is very likely that SSL certificate errors occur in different parts of the application, most likely Sidekiq. There are two approaches you can take to solve this: diff --git a/doc/integration/cas.md b/doc/integration/cas.md index e61988c3301..6b8da8ecbd5 100644 --- a/doc/integration/cas.md +++ b/doc/integration/cas.md @@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w # CAS OmniAuth Provider -To enable the CAS OmniAuth provider you must register your application with your CAS instance. This requires the service URL GitLab will supply to CAS. It should be something like: `https://gitlab.example.com:443/users/auth/cas3/callback?url`. By default handling for SLO is enabled, you only need to configure CAS for backchannel logout. +To enable the CAS OmniAuth provider you must register your application with your CAS instance. This requires the service URL GitLab supplies to CAS. It should be something like: `https://gitlab.example.com:443/users/auth/cas3/callback?url`. By default handling for SLO is enabled, you only need to configure CAS for backchannel logout. 1. On your GitLab server, open the configuration file. diff --git a/doc/integration/chat_commands.md b/doc/integration/chat_commands.md index 1a4fb46046d..a0361064d87 100644 --- a/doc/integration/chat_commands.md +++ b/doc/integration/chat_commands.md @@ -3,3 +3,6 @@ redirect_to: 'slash_commands.md' --- This document was moved to [integration/slash_commands.md](slash_commands.md). + +<!-- This redirect file can be deleted after February 1, 2021. --> +<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page --> diff --git a/doc/integration/crowd.md b/doc/integration/crowd.md index 30e3e888b29..e07e3435baf 100644 --- a/doc/integration/crowd.md +++ b/doc/integration/crowd.md @@ -3,3 +3,6 @@ redirect_to: '../administration/auth/crowd.md' --- This document was moved to [`administration/auth/crowd`](../administration/auth/crowd.md). + +<!-- This redirect file can be deleted after February 1, 2021. --> +<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page --> diff --git a/doc/integration/elasticsearch.md b/doc/integration/elasticsearch.md index 095c58f17fc..8597e310b91 100644 --- a/doc/integration/elasticsearch.md +++ b/doc/integration/elasticsearch.md @@ -23,8 +23,8 @@ and the advantage of the following special searches: | GitLab version | Elasticsearch version | |---------------------------------------------|-------------------------------| -| GitLab Enterprise Edition 13.6 or greater | Elasticsearch 7.x (6.4 - 6.x deprecated to be removed in 13.8) | -| GitLab Enterprise Edition 13.2 through 13.5 | Elasticsearch 6.4 through 7.x | +| GitLab Enterprise Edition 13.9 or greater | Elasticsearch 6.8 through 7.x | +| GitLab Enterprise Edition 13.3 through 13.8 | Elasticsearch 6.4 through 7.x | | GitLab Enterprise Edition 12.7 through 13.2 | Elasticsearch 6.x through 7.x | | GitLab Enterprise Edition 11.5 through 12.6 | Elasticsearch 5.6 through 6.x | | GitLab Enterprise Edition 9.0 through 11.4 | Elasticsearch 5.1 through 5.5 | @@ -435,6 +435,55 @@ After the reindexing is completed, the original index will be scheduled to be de While the reindexing is running, you will be able to follow its progress under that same section. +## Background migrations + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/234046) in GitLab 13.6. + +With reindex migrations running in the background, there's no need for a manual +intervention. This usually happens in situations where new features are added to +Advanced Search, which means adding or changing the way content is indexed. + +To confirm that the background migrations ran, you can check with: + +```shell +curl "$CLUSTER_URL/gitlab-production-migrations/_search?q=*" | jq . +``` + +This should return something similar to: + +```json +{ + "took": 14, + "timed_out": false, + "_shards": { + "total": 1, + "successful": 1, + "skipped": 0, + "failed": 0 + }, + "hits": { + "total": { + "value": 1, + "relation": "eq" + }, + "max_score": 1, + "hits": [ + { + "_index": "gitlab-production-migrations", + "_type": "_doc", + "_id": "20201105181100", + "_score": 1, + "_source": { + "completed": true + } + } + ] + } +} +``` + +In order to debug issues with the migrations you can check the [`elasticsearch.log` file](../administration/logs.md#elasticsearchlog). + ## GitLab Advanced Search Rake tasks Rake tasks are available to: @@ -712,6 +761,17 @@ However, some larger installations may wish to tune the merge policy settings: ## Troubleshooting +One of the most valuable tools for identifying issues with the Elasticsearch +integration will be logs. The most relevant logs for this integration are: + +1. [`sidekiq.log`](../administration/logs.md#sidekiqlog) - All of the + indexing happens in Sidekiq, so much of the relevant logs for the + Elasticsearch integration can be found in this file. +1. [`elasticsearch.log`](../administration/logs.md#elasticsearchlog) - There + are additional logs specific to Elasticsearch that are sent to this file + that may contain useful diagnostic information about searching, + indexing or migrations. + Here are some common pitfalls and how to overcome them. ### How can I verify that my GitLab instance is using Elasticsearch? @@ -869,6 +929,13 @@ Gitlab::Elastic::Indexer::Error: time="2020-01-23T09:13:00Z" level=fatal msg="he You probably have not used either `http://` or `https://` as part of your value in the **"URL"** field of the Elasticsearch Integration Menu. Please make sure you are using either `http://` or `https://` in this field as the [Elasticsearch client for Go](https://github.com/olivere/elastic) that we are using [needs the prefix for the URL to be accepted as valid](https://github.com/olivere/elastic/commit/a80af35aa41856dc2c986204e2b64eab81ccac3a). Once you have corrected the formatting of the URL, delete the index (via the [dedicated Rake task](#gitlab-advanced-search-rake-tasks)) and [reindex the content of your instance](#enabling-advanced-search). +### My Elasticsearch cluster has a plugin and the integration is not working + +Certain 3rd party plugins may introduce bugs in your cluster or for whatever +reason may be incompatible with our integration. You should try disabling +plugins so you can rule out the possibility that the plugin is causing the +problem. + ### Low-level troubleshooting There is a [more structured, lower-level troubleshooting document](../administration/troubleshooting/elasticsearch.md) for when you experience other issues, including poor performance. diff --git a/doc/integration/facebook.md b/doc/integration/facebook.md index bb699fa90b7..c53e81bf50b 100644 --- a/doc/integration/facebook.md +++ b/doc/integration/facebook.md @@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Facebook OAuth2 OmniAuth Provider -To enable the Facebook OmniAuth provider you must register your application with Facebook. Facebook will generate an app ID and secret key for you to use. +To enable the Facebook OmniAuth provider you must register your application with Facebook. Facebook generates an app ID and secret key for you to use. 1. Sign in to the [Facebook Developer Platform](https://developers.facebook.com/). @@ -101,4 +101,4 @@ To enable the Facebook OmniAuth provider you must register your application with 1. [Reconfigure](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart GitLab](../administration/restart_gitlab.md#installations-from-source) for the changes to take effect if you installed GitLab via Omnibus or from source respectively. -On the sign in page there should now be a Facebook icon below the regular sign in form. Click the icon to begin the authentication process. Facebook will ask the user to sign in and authorize the GitLab application. If everything goes well the user will be returned to GitLab and will be signed in. +On the sign in page there should now be a Facebook icon below the regular sign in form. Click the icon to begin the authentication process. Facebook asks the user to sign in and authorize the GitLab application. If everything goes well the user is returned to GitLab and signed in. diff --git a/doc/integration/github.md b/doc/integration/github.md index 8407920c631..b6a8de42beb 100644 --- a/doc/integration/github.md +++ b/doc/integration/github.md @@ -12,9 +12,9 @@ with your GitHub account. ## Enabling GitHub OAuth -To enable the GitHub OmniAuth provider, you'll need an OAuth 2 Client ID and Client Secret from GitHub. To get these credentials, sign into GitHub and follow their procedure for [Creating an OAuth App](https://developer.github.com/apps/building-oauth-apps/creating-an-oauth-app/). +To enable the GitHub OmniAuth provider, you need an OAuth 2 Client ID and Client Secret from GitHub. To get these credentials, sign into GitHub and follow their procedure for [Creating an OAuth App](https://developer.github.com/apps/building-oauth-apps/creating-an-oauth-app/). -When you create an OAuth 2 app in GitHub, you'll need the following information: +When you create an OAuth 2 app in GitHub, you need the following information: - The URL of your GitLab instance, such as `https://gitlab.example.com`. - The authorization callback URL; in this case, `https://gitlab.example.com/users/auth`. Include the port number if your GitLab instance uses a non-default port. @@ -24,7 +24,7 @@ To prevent an [OAuth2 covert redirect](https://oauth.net/advisories/2014-1-cover See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings. -Once you have configured the GitHub provider, you'll need the following information, which you'll need to substitute in the GitLab configuration file, in the steps shown next. +After you have configured the GitHub provider, you need the following information, which you must substitute in the GitLab configuration file, in the steps shown next. | Setting from GitHub | Substitute in the GitLab configuration file | Description | |:---------------------|:---------------------------------------------|:------------| @@ -101,12 +101,12 @@ Follow these steps to incorporate the GitHub OAuth 2 app in your GitLab server: 1. Refresh the GitLab sign in page. You should now see a GitHub icon below the regular sign in form. -1. Click the icon to begin the authentication process. GitHub will ask the user to sign in and authorize the GitLab application. +1. Click the icon to begin the authentication process. GitHub asks the user to sign in and authorize the GitLab application. ## GitHub Enterprise with self-signed Certificate If you are attempting to import projects from GitHub Enterprise with a self-signed -certificate and the imports are failing, you will need to disable SSL verification. +certificate and the imports are failing, you must disable SSL verification. It should be disabled by adding `verify_ssl` to `false` in the provider configuration and changing the global Git `sslVerify` option to `false` in the GitLab server. @@ -125,7 +125,7 @@ gitlab_rails['omniauth_providers'] = [ ] ``` -You will also need to disable Git SSL verification on the server hosting GitLab. +You must also disable Git SSL verification on the server hosting GitLab. ```ruby omnibus_gitconfig['system'] = { "http" => ["sslVerify = false"] } @@ -142,7 +142,7 @@ For installation from source: args: { scope: 'user:email' } } ``` -You will also need to disable Git SSL verification on the server hosting GitLab. +You must also disable Git SSL verification on the server hosting GitLab. ```shell git config --global http.sslVerify false diff --git a/doc/integration/gitlab.md b/doc/integration/gitlab.md index c618d226290..29d0fa02570 100644 --- a/doc/integration/gitlab.md +++ b/doc/integration/gitlab.md @@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w Import projects from GitLab.com and login to your GitLab instance with your GitLab.com account. To enable the GitLab.com OmniAuth provider you must register your application with GitLab.com. -GitLab.com will generate an application ID and secret key for you to use. +GitLab.com generates an application ID and secret key for you to use. 1. Sign in to GitLab.com @@ -85,5 +85,5 @@ GitLab.com will generate an application ID and secret key for you to use. installed GitLab via Omnibus or from source respectively. On the sign in page there should now be a GitLab.com icon below the regular sign in form. -Click the icon to begin the authentication process. GitLab.com will ask the user to sign in and authorize the GitLab application. -If everything goes well the user will be returned to your GitLab instance and will be signed in. +Click the icon to begin the authentication process. GitLab.com asks the user to sign in and authorize the GitLab application. +If everything goes well the user is returned to your GitLab instance and is signed in. diff --git a/doc/integration/gmail_action_buttons_for_gitlab.md b/doc/integration/gmail_action_buttons_for_gitlab.md index 72196fd0f52..fccb190d529 100644 --- a/doc/integration/gmail_action_buttons_for_gitlab.md +++ b/doc/integration/gmail_action_buttons_for_gitlab.md @@ -8,15 +8,14 @@ info: To determine the technical writer assigned to the Stage/Group associated w GitLab supports [Google actions in email](https://developers.google.com/gmail/markup/actions/actions-overview). -If correctly set up, emails that require an action will be marked in Gmail. +If correctly set up, emails that require an action are marked in Gmail.  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.* +*This process has a lot of steps so make sure that you fulfill all requirements set by Google to avoid your application being rejected by Google.* In particular, note: @@ -25,6 +24,6 @@ In particular, note: (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. +- Before sending the final form ("Gmail Schema Whitelist Request"), you must send a real email from your production server. This means that you must 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. You can check how it looks going through all the steps laid out in the "Registering with Google" doc in [this GitLab.com issue](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/1517). diff --git a/doc/integration/google.md b/doc/integration/google.md index cd40aaff30a..c4607d6b9f2 100644 --- a/doc/integration/google.md +++ b/doc/integration/google.md @@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Google OAuth2 OmniAuth Provider To enable the Google OAuth2 OmniAuth provider you must register your application -with Google. Google will generate a client ID and secret key for you to use. +with Google. Google generates a client ID and secret key for you to use. ## Enabling Google OAuth @@ -40,7 +40,7 @@ In Google's side: ``` 1. You should now be able to see a Client ID and Client secret. Note them down - or keep this page open as you will need them later. + or keep this page open as you need them later. 1. To enable projects to access [Google Kubernetes Engine](../user/project/clusters/index.md), you must also enable these APIs: - Google Kubernetes Engine API @@ -98,7 +98,7 @@ On your GitLab server: 1. Change `YOUR_APP_ID` to the client ID from the Google Developer page 1. Similarly, change `YOUR_APP_SECRET` to the client secret -1. Make sure that you configure GitLab to use an FQDN as Google will not accept +1. Make sure that you configure GitLab to use a fully-qualified domain name, as Google doesn't accept raw IP addresses. For Omnibus packages: @@ -119,6 +119,6 @@ On your GitLab server: installed GitLab via Omnibus or from source respectively. On the sign in page there should now be a Google icon below the regular sign in -form. Click the icon to begin the authentication process. Google will ask the +form. Click the icon to begin the authentication process. Google asks the user to sign in and authorize the GitLab application. If everything goes well -the user will be returned to GitLab and will be signed in. +the user is returned to GitLab and is signed in. diff --git a/doc/integration/img/sourcegraph_admin_v12_5.png b/doc/integration/img/sourcegraph_admin_v12_5.png Binary files differindex 54511541c87..e42371a681e 100644 --- a/doc/integration/img/sourcegraph_admin_v12_5.png +++ b/doc/integration/img/sourcegraph_admin_v12_5.png diff --git a/doc/integration/jenkins.md b/doc/integration/jenkins.md index 7eb147c1fe6..9fd82c22e8f 100644 --- a/doc/integration/jenkins.md +++ b/doc/integration/jenkins.md @@ -54,9 +54,9 @@ Grant a GitLab user access to the select GitLab projects. 1. Create a new GitLab user, or choose an existing GitLab user. - This account will be used by Jenkins to access the GitLab projects. We recommend creating a GitLab + This account is used by Jenkins to access the GitLab projects. We recommend creating a GitLab user for only this purpose. If you use a person's account, and their account is deactivated or - deleted, the GitLab-Jenkins integration will stop working. + deleted, the GitLab-Jenkins integration stops working. 1. Grant the user permission to the GitLab projects. @@ -96,12 +96,12 @@ For more information, see GitLab Plugin documentation about ## Configure the Jenkins project -Set up the Jenkins project you’re going to run your build on. +Set up the Jenkins project you intend to run your build on. 1. On your Jenkins instance, go to **New Item**. 1. Enter the project's name. 1. Choose between **Freestyle** or **Pipeline** and click **OK**. - We recommend a Freestyle project, because the Jenkins plugin will update the build status on + We recommend a Freestyle project, because the Jenkins plugin updates the build status on GitLab. In a Pipeline project, you must configure a script to update the status on GitLab. 1. Choose your GitLab connection from the dropdown. 1. Check the **Build when a change is pushed to GitLab** checkbox. @@ -186,7 +186,7 @@ If those are present, the request is exceeding the [webhook timeout](../user/project/integrations/webhooks.md#receiving-duplicate-or-multiple-webhook-requests-triggered-by-one-event), which is set to 10 seconds by default. -To fix this the `gitlab_rails['webhook_timeout']` value will need to be increased +To fix this the `gitlab_rails['webhook_timeout']` value must be increased in the `gitlab.rb` config file, followed by the [`gitlab-ctl reconfigure` command](../administration/restart_gitlab.md). If you don't find the errors above, but do find *duplicate* entries like below (in `/var/log/gitlab/gitlab-rail`), this diff --git a/doc/integration/jenkins_deprecated.md b/doc/integration/jenkins_deprecated.md index 63d5ac48765..d68923ed137 100644 --- a/doc/integration/jenkins_deprecated.md +++ b/doc/integration/jenkins_deprecated.md @@ -41,7 +41,7 @@ In GitLab, perform the following steps. Jenkins needs read access to the GitLab repository. We already specified a private key to use in Jenkins, now we need to add a public one to the GitLab -project. For that case we will need a Deploy key. Read the documentation on +project. For that case we need a Deploy key. Read the documentation on [how to set up a Deploy key](../ssh/README.md#deploy-keys). ### Jenkins service @@ -50,14 +50,13 @@ Now navigate to GitLab services page and activate Jenkins  -Done! Now when you push to GitLab - it will create a build for Jenkins. -And also you will be able to see merge request build status with a link to the Jenkins build. +Done! Now when you push to GitLab - it creates a build for Jenkins, and you can view the merge request build status with a link to the Jenkins build. ### Multi-project Configuration The GitLab Hook plugin in Jenkins supports the automatic creation of a project -for each feature branch. After configuration GitLab will trigger feature branch -builds and a corresponding project will be created in Jenkins. +for each feature branch. After configuration GitLab triggers feature branch +builds and a corresponding project is created in Jenkins. Configure the GitLab Hook plugin in Jenkins. Go to 'Manage Jenkins' and then 'Configure System'. Find the 'GitLab Web Hook' section and configure as shown below. diff --git a/doc/integration/jira.md b/doc/integration/jira.md index 37eba25fb5a..0e22bedd1cc 100644 --- a/doc/integration/jira.md +++ b/doc/integration/jira.md @@ -3,3 +3,6 @@ redirect_to: '../user/project/integrations/jira.md' --- This document was moved to [another location](../user/project/integrations/jira.md). + +<!-- This redirect file can be deleted after February 1, 2021. --> +<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page --> diff --git a/doc/integration/ldap.md b/doc/integration/ldap.md index 25e4cc52375..55c169bca80 100644 --- a/doc/integration/ldap.md +++ b/doc/integration/ldap.md @@ -3,3 +3,6 @@ redirect_to: '../administration/auth/ldap/index.md' --- This document was moved to [`administration/auth/ldap`](../administration/auth/ldap/index.md). + +<!-- This redirect file can be deleted after February 1, 2021. --> +<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page --> diff --git a/doc/integration/oauth2_generic.md b/doc/integration/oauth2_generic.md index 5957af292ab..cfa846decf8 100644 --- a/doc/integration/oauth2_generic.md +++ b/doc/integration/oauth2_generic.md @@ -20,7 +20,7 @@ This strategy is designed to allow configuration of the simple OmniAuth SSO proc ## Limitations of this Strategy -- It can only be used for Single Sign on, and will not provide any other access granted by any OAuth provider +- It can only be used for Single Sign on, and doesn't provide any other access granted by any OAuth provider (importing projects or users, etc) - It only supports the Authorization Grant flow (most common for client-server applications, like GitLab) - It is not able to fetch user information from more than one URL @@ -37,7 +37,7 @@ This strategy is designed to allow configuration of the simple OmniAuth SSO proc ``` 1. You should now be able to get a Client ID and Client Secret. - Where this shows up will differ for each provider. + Where this shows up differs for each provider. This may also be called Application ID and Secret 1. On your GitLab server, open the configuration file. @@ -64,6 +64,6 @@ This strategy is designed to allow configuration of the simple OmniAuth SSO proc 1. Restart GitLab for the changes to take effect On the sign in page there should now be a new button below the regular sign in form. -Click the button to begin your provider's authentication process. This will direct +Click the button to begin your provider's authentication process. This directs the browser to your OAuth2 Provider's authentication page. If everything goes well -the user will be returned to your GitLab instance and will be signed in. +the user is returned to your GitLab instance and is signed in. diff --git a/doc/integration/oauth_provider.md b/doc/integration/oauth_provider.md index 68d10a3135e..0819e949915 100644 --- a/doc/integration/oauth_provider.md +++ b/doc/integration/oauth_provider.md @@ -48,12 +48,12 @@ In order to add a new application via your profile, navigate to  In the application form, enter a **Name** (arbitrary), and make sure to set up -correctly the **Redirect URI** which is the URL where users will be sent after +correctly the **Redirect URI** which is the URL where users are sent after they authorize with GitLab.  -When you hit **Submit** you will be provided with the application ID and +When you click **Submit** you are provided with the application ID and the application secret which you can then use with your application that connects to GitLab. @@ -71,7 +71,7 @@ the user authorization step is automatically skipped for this application. ## Authorized applications -Every application you authorized to use your GitLab credentials will be shown +Every application you authorized to use your GitLab credentials is shown in the **Authorized applications** section under **Profile Settings > Applications**.  diff --git a/doc/integration/omniauth.md b/doc/integration/omniauth.md index eebafab2693..95d672ee89d 100644 --- a/doc/integration/omniauth.md +++ b/doc/integration/omniauth.md @@ -51,23 +51,23 @@ that are in common for all providers that we need to consider. NOTE: **Note:** Starting from GitLab 11.4, OmniAuth is enabled by default. If you're using an -earlier version, you'll need to explicitly enable it. +earlier version, you must explicitly enable it. - `allow_single_sign_on` allows you to specify the providers you want to allow to automatically create an account. It defaults to `false`. If `false` users must - be created manually or they will not be able to sign in via OmniAuth. + be created manually or they can't sign in via OmniAuth. - `auto_link_ldap_user` can be used if you have [LDAP / ActiveDirectory](../administration/auth/ldap/index.md) integration enabled. It defaults to `false`. When enabled, users automatically - created through an OmniAuth provider will have their LDAP identity created in GitLab as well. + created through an OmniAuth provider have their LDAP identity created in GitLab as well. - `block_auto_created_users` defaults to `true`. If `true` auto created users will - be blocked by default and will have to be unblocked by an administrator before + be blocked by default and must be unblocked by an administrator before they are able to sign in. NOTE: **Note:** If you set `block_auto_created_users` to `false`, make sure to only define providers under `allow_single_sign_on` that you are able to control, like SAML, Shibboleth, Crowd or Google, or set it to `false` otherwise any user on -the Internet will be able to successfully sign in to your GitLab without +the Internet can successfully sign in to your GitLab without administrative approval. NOTE: **Note:** @@ -141,8 +141,8 @@ OmniAuth provider for an existing user. 1. Go to profile settings (the silhouette icon in the top right corner). 1. Select the "Account" tab. 1. Under "Connected Accounts" select the desired OmniAuth provider, such as Twitter. -1. The user will be redirected to the provider. Once the user authorized GitLab - they will be redirected back to GitLab. +1. The user is redirected to the provider. After the user authorizes GitLab, + they are redirected back to GitLab. The chosen OmniAuth provider is now active and can be used to sign in to GitLab from then on. @@ -171,8 +171,8 @@ omniauth: > Introduced in GitLab 8.7. You can define which OmniAuth providers you want to be `external` so that all users -**creating accounts, or logging in via these providers** will not be able to have -access to internal projects. You will need to use the full name of the provider, +**creating accounts, or logging in via these providers** can't have +access to internal projects. You must use the full name of the provider, like `google_oauth2` for Google. Refer to the examples for the full names of the supported providers. @@ -206,7 +206,7 @@ these cases you can use the OmniAuth provider. ### Steps -These steps are fairly general and you will need to figure out the exact details +These steps are fairly general and you must figure out the exact details from the OmniAuth provider's documentation. - Stop GitLab: @@ -343,8 +343,8 @@ omniauth: auto_sign_in_with_provider: azure_oauth2 ``` -Keep in mind that every sign-in attempt will be redirected to the OmniAuth -provider; you won't be able to sign in using local credentials. Ensure at least +Keep in mind that every sign-in attempt is redirected to the OmniAuth +provider; you can't sign in using local credentials. Ensure at least one of the OmniAuth users has admin permissions. You may also bypass the auto sign in feature by browsing to diff --git a/doc/integration/salesforce.md b/doc/integration/salesforce.md index 3290f18e2cb..4f4f9b3e3d1 100644 --- a/doc/integration/salesforce.md +++ b/doc/integration/salesforce.md @@ -82,8 +82,8 @@ To get the credentials (a pair of Client ID and Client Secret), you must [create 1. [Reconfigure GitLab]( ../administration/restart_gitlab.md#omnibus-gitlab-reconfigure ) or [restart GitLab]( ../administration/restart_gitlab.md#installations-from-source ) for the changes to take effect if you installed GitLab via Omnibus or from source respectively. On the sign in page, there should now be a Salesforce icon below the regular sign in form. -Click the icon to begin the authentication process. Salesforce will ask the user to sign in and authorize the GitLab application. -If everything goes well, the user will be returned to GitLab and will be signed in. +Click the icon to begin the authentication process. Salesforce asks the user to sign in and authorize the GitLab application. +If everything goes well, the user is returned to GitLab and is signed in. NOTE: **Note:** -GitLab requires the email address of each new user. Once the user is logged in using Salesforce, GitLab will redirect the user to the profile page where they will have to provide the email and verify the email. +GitLab requires the email address of each new user. Once the user is logged in using Salesforce, GitLab redirects the user to the profile page where they must provide the email and verify the email. diff --git a/doc/integration/shibboleth.md b/doc/integration/shibboleth.md index 59374d8ad6f..d59ecca0b8d 100644 --- a/doc/integration/shibboleth.md +++ b/doc/integration/shibboleth.md @@ -54,10 +54,10 @@ The following changes are needed to enable Shibboleth: NOTE: **Note:** Starting from GitLab 11.4, OmniAuth is enabled by default. If you're using an - earlier version, you'll need to explicitly enable it in `/etc/gitlab/gitlab.rb`. + earlier version, you must explicitly enable it in `/etc/gitlab/gitlab.rb`. 1. In addition, add Shibboleth to `/etc/gitlab/gitlab.rb` as an OmniAuth provider. - User attributes will be sent from the + User attributes are sent from the Apache reverse proxy to GitLab as headers with the names from the Shibboleth attribute mapping. Therefore the values of the `args` hash should be in the form of `"HTTP_ATTRIBUTE"`. The keys in the hash are arguments @@ -100,12 +100,12 @@ The following changes are needed to enable Shibboleth: 1. [Reconfigure](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart](../administration/restart_gitlab.md#installations-from-source) GitLab for the changes to take effect if you installed GitLab via Omnibus or from source respectively. -On the sign in page, there should now be a "Sign in with: Shibboleth" icon below the regular sign in form. Click the icon to begin the authentication process. You will be redirected to IdP server (depends on your Shibboleth module configuration). If everything goes well the user will be returned to GitLab and will be signed in. +On the sign in page, there should now be a "Sign in with: Shibboleth" icon below the regular sign in form. Click the icon to begin the authentication process. You are redirected to IdP server (depends on your Shibboleth module configuration). If everything goes well the user is returned to GitLab and is signed in. ## Apache 2.4 / GitLab 8.6 update The order of the first 2 Location directives is important. If they are reversed, -you will not get a Shibboleth session! +requesting a Shibboleth session fails! ```plaintext <Location /> diff --git a/doc/integration/slack.md b/doc/integration/slack.md index 815032a08d5..fbea9d3035c 100644 --- a/doc/integration/slack.md +++ b/doc/integration/slack.md @@ -3,3 +3,6 @@ redirect_to: '../user/project/integrations/slack.md' --- This document was moved to [another location](../user/project/integrations/slack.md). + +<!-- This redirect file can be deleted after February 1, 2021. --> +<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page --> diff --git a/doc/integration/slash_commands.md b/doc/integration/slash_commands.md index ea2c4b3e93f..502475931b6 100644 --- a/doc/integration/slash_commands.md +++ b/doc/integration/slash_commands.md @@ -37,11 +37,11 @@ It is possible to create new issue, display issue details and search up to 5 iss ## Deploy command -In order to deploy to an environment, GitLab will try to find a deployment +In order to deploy to an environment, GitLab tries to find a deployment manual action in the pipeline. -If there is only one action for a given environment, it is going to be triggered. -If there is more than one action defined, GitLab will try to find an action +If there is only one action for a given environment, it is triggered. +If there is more than one action defined, GitLab tries to find an action which name equals the environment name we want to deploy to. -Command will return an error when no matching action has been found. +The command returns an error when no matching action has been found. diff --git a/doc/integration/sourcegraph.md b/doc/integration/sourcegraph.md index 47c84643a7d..4bbb34b5fda 100644 --- a/doc/integration/sourcegraph.md +++ b/doc/integration/sourcegraph.md @@ -64,6 +64,8 @@ Feature.enable(:sourcegraph, Project.find_by_full_path('my_group/my_project')) If you are new to Sourcegraph, head over to the [Sourcegraph installation documentation](https://docs.sourcegraph.com/admin) and get your instance up and running. +If you are using an HTTPS connection to GitLab, you will need to [configure HTTPS](https://docs.sourcegraph.com/admin/http_https_configuration) for your Sourcegraph instance. + ### Connect your Sourcegraph instance to your GitLab instance 1. Navigate to the site admin area in Sourcegraph. diff --git a/doc/integration/trello_power_up.md b/doc/integration/trello_power_up.md index 22481e14236..4ad9d2c2b3a 100644 --- a/doc/integration/trello_power_up.md +++ b/doc/integration/trello_power_up.md @@ -13,7 +13,7 @@ GitLab **merge requests** to Trello cards. ## Configuring the Power-Up -In order to get started, you will need to configure your Power-Up. +In order to get started, you must configure your Power-Up. In Trello: @@ -23,19 +23,19 @@ In Trello: 1. Select the `Settings` (gear) icon 1. In the popup menu, select `Authorize Account` -In this popup, fill in your `API URL` and `Personal Access Token`. After that, you will be able to attach any merge request to any Trello card on your selected Trello board. +In this popup, fill in your `API URL` and `Personal Access Token`. After that, you can attach any merge request to any Trello card on your selected Trello board. ## What is my API URL? Your API URL should be your GitLab instance URL with `/api/v4` appended in the end of the URL. For example, if your GitLab instance URL is `https://gitlab.com`, your API URL would be `https://gitlab.com/api/v4`. -If your instance's URL is `https://example.com`, your API URL will be `https://example.com/api/v4`. +If your instance's URL is `https://example.com`, your API URL is `https://example.com/api/v4`.  ## What is my Personal Access Token? -Your GitLab's personal access token will enable your GitLab account to be accessed +Your GitLab's personal access token enables your GitLab account to be accessed from Trello. > Find it in GitLab by clicking on your avatar (upright corner), from which you access diff --git a/doc/integration/twitter.md b/doc/integration/twitter.md index bfe18c43e9d..507d2b965a4 100644 --- a/doc/integration/twitter.md +++ b/doc/integration/twitter.md @@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Twitter OAuth2 OmniAuth Provider -To enable the Twitter OmniAuth provider you must register your application with Twitter. Twitter will generate a client ID and secret key for you to use. +To enable the Twitter OmniAuth provider you must register your application with Twitter. Twitter generates a client ID and secret key for you to use. 1. Sign in to [Twitter Application Management](https://developer.twitter.com/apps). @@ -85,4 +85,4 @@ To enable the Twitter OmniAuth provider you must register your application with 1. [Reconfigure](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart GitLab](../administration/restart_gitlab.md#installations-from-source) for the changes to take effect if you installed GitLab via Omnibus or from source respectively. -On the sign in page there should now be a Twitter icon below the regular sign in form. Click the icon to begin the authentication process. Twitter will ask the user to sign in and authorize the GitLab application. If everything goes well the user will be returned to GitLab and will be signed in. +On the sign in page there should now be a Twitter icon below the regular sign in form. Click the icon to begin the authentication process. Twitter asks the user to sign in and authorize the GitLab application. If everything goes well the user is returned to GitLab and signed in. |
