Commit 40caa9d0 authored by Mike Lewis's avatar Mike Lewis

Merge branch 'deuley-updating-integrations-overview' into 'master'

Updating integrations overview documentation

See merge request gitlab-org/gitlab!36496
parents 907ebcb7 33cfb2c1
...@@ -14,8 +14,6 @@ want to configure. ...@@ -14,8 +14,6 @@ want to configure.
![Integrations list](img/project_services.png) ![Integrations list](img/project_services.png)
Below, you will find a list of the currently supported ones accompanied with comprehensive documentation.
## Integrations listing ## Integrations listing
Click on the service links to see further configuration instructions and details. Click on the service links to see further configuration instructions and details.
...@@ -69,16 +67,16 @@ supported by `push_hooks` and `tag_push_hooks` events won't be executed. ...@@ -69,16 +67,16 @@ supported by `push_hooks` and `tag_push_hooks` events won't be executed.
The number of branches or tags supported can be changed via The number of branches or tags supported can be changed via
[`push_event_hooks_limit` application setting](../../../api/settings.md#list-of-settings-that-can-be-accessed-via-api-calls). [`push_event_hooks_limit` application setting](../../../api/settings.md#list-of-settings-that-can-be-accessed-via-api-calls).
## Services templates ## Service templates
Services templates is a way to set some predefined values in the Service of Service templates are a way to set predefined values for an integration across
your liking which will then be pre-filled on each project's Service. all new projects on the instance.
Read more about [Services templates in this document](services_templates.md). Read more about [Service templates in this document](services_templates.md).
## Troubleshooting integrations ## Troubleshooting integrations
Some integrations use service hooks for integration with external applications. To confirm which ones use service hooks, see the [integrations listing](#integrations-listing). GitLab stores details of service hook requests made within the last 2 days. To view details of the requests, go to the service's configuration page. Some integrations use service hooks for integration with external applications. To confirm which ones use service hooks, see the [integrations listing](#integrations-listing) above. GitLab stores details of service hook requests made within the last 2 days. To view details of the requests, go to that integration's configuration page.
The **Recent Deliveries** section lists the details of each request made within the last 2 days: The **Recent Deliveries** section lists the details of each request made within the last 2 days:
...@@ -89,17 +87,17 @@ The **Recent Deliveries** section lists the details of each request made within ...@@ -89,17 +87,17 @@ The **Recent Deliveries** section lists the details of each request made within
- Relative time in which the request was made - Relative time in which the request was made
To view more information about the request's execution, click the respective **View details** link. To view more information about the request's execution, click the respective **View details** link.
On the details page, you can see the data sent by GitLab (request headers and body) and the data received by GitLab (response headers and body). On the details page, you can see the request headers and body sent and received by GitLab.
From this page, you can repeat delivery with the same data by clicking **Resend Request**. To repeat a delivery using the same data, click **Resend Request**.
![Recent deliveries](img/webhook_logs.png) ![Recent deliveries](img/webhook_logs.png)
### Uninitialized repositories ### Uninitialized repositories
Some integrations fail with an error `Test Failed. Save Anyway` when you attempt to set them up on Some integrations fail with an error `Test Failed. Save Anyway` when you attempt to set them up on
uninitialized repositories. This is because the default service test uses push data to build the uninitialized repositories. Some integrations use push data to build the test payload,
payload for the test request, and it fails, because there are no push events for the project. and this error occurs when no push events exist in the project yet.
To resolve this error, initialize the repository by pushing a test file to the project and set up To resolve this error, initialize the repository by pushing a test file to the project and set up
the integration again. the integration again.
......
# Services templates # Service templates
A GitLab administrator can add a service template that sets a default for each Using a service template, GitLab administrators can provide default values for configuring integrations at the project level.
project. After a service template is enabled, it will be applied to **all**
projects that don't have it already enabled and its details will be pre-filled When you enable a service template, the defaults are applied to **all** projects that do not
on the project's Service page. By disabling the template, it will be disabled already have the integration enabled or do not otherwise have custom values saved.
for new projects only. The values are pre-filled on each project's configuration page for the applicable integration.
If you disable the template, these values no longer appear as defaults, while
any values already saved for an integration remain unchanged.
## Enable a service template ## Enable a service template
Navigate to the **Admin Area > Service Templates** and choose the service Navigate to the **Admin Area > Service Templates** and choose the service
template you wish to create. template you wish to create.
## Services for external issue trackers ## Service for external issue trackers
In the image below you can see how a service template for Redmine would look The following image shows an example service template for Redmine.
like.
![Redmine service template](img/services_templates_redmine_example.png) ![Redmine service template](img/services_templates_redmine_example.png)
---
For each project, you will still need to configure the issue tracking For each project, you will still need to configure the issue tracking
URLs by replacing `:issues_tracker_id` in the above screenshot with the ID used URLs by replacing `:issues_tracker_id` in the above screenshot with the ID used
by your external issue tracker. Prior to GitLab v7.8, this ID was configured in by your external issue tracker.
the project settings, and GitLab would automatically update the URL configured
in `gitlab.yml`. This behavior is now deprecated and all issue tracker URLs
must be configured directly within the project's **Integrations** settings.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment