summaryrefslogtreecommitdiff
path: root/doc/ci/review_apps/index.md
diff options
context:
space:
mode:
Diffstat (limited to 'doc/ci/review_apps/index.md')
-rw-r--r--doc/ci/review_apps/index.md22
1 files changed, 11 insertions, 11 deletions
diff --git a/doc/ci/review_apps/index.md b/doc/ci/review_apps/index.md
index 31fcfe9d6e8..3512b77e4e2 100644
--- a/doc/ci/review_apps/index.md
+++ b/doc/ci/review_apps/index.md
@@ -69,7 +69,7 @@ The process of configuring Review Apps is as follows:
When configuring Review Apps for a project, you need to add a new job to `.gitlab-ci.yml`,
as mentioned above. To facilitate this and if you are using Kubernetes, you can click
-the **Enable Review Apps** button and GitLab will prompt you with a template code block that
+the **Enable Review Apps** button and GitLab prompts you with a template code block that
you can copy and paste into `.gitlab-ci.yml` as a starting point. To do so:
1. Go to the project your want to create a Review App job for.
@@ -115,7 +115,7 @@ and faster to preview proposed modifications.
Configuring Route Maps involves telling GitLab how the paths of files
in your repository map to paths of pages on your website using a Route Map.
-Once set, GitLab will display **View on ...** buttons, which will take you
+Once set, GitLab displays **View on ...** buttons, which take you
to the pages changed directly from merge requests.
To set up a route map, add a file inside the repository at `.gitlab/route-map.yml`,
@@ -165,15 +165,15 @@ The public path for a source path is determined by finding the first
In the example above, the fact that mappings are evaluated in order
of their definition is used to ensure that `source/index.html.haml`
-will match `/source\/(.+?\.html).*/` instead of `/source\/(.*)/`,
-and will result in a public path of `index.html`, instead of
+matches `/source\/(.+?\.html).*/` instead of `/source\/(.*)/`,
+and results in a public path of `index.html`, instead of
`index.html.haml`.
-After you have the route mapping set up, it will take effect in the following locations:
+After you have the route mapping set up, it takes effect in the following locations:
- In the merge request widget. The:
- - **View app** button will take you to the environment URL set in `.gitlab-ci.yml`.
- - Dropdown will list the first 5 matched items from the route map, but you can filter them if more
+ - **View app** button takes you to the environment URL set in `.gitlab-ci.yml`.
+ - Dropdown lists the first 5 matched items from the route map, but you can filter them if more
than 5 are available.
![View app file list in merge request widget](img/view_on_mr_widget.png)
@@ -221,7 +221,7 @@ To see Visual reviews in action, see the [Visual Reviews Walk through](https://y
The feedback form is served through a script you add to pages in your Review App.
If you have [Developer permissions](../../user/permissions.md) to the project,
you can access it by clicking the **Review** button in the **Pipeline** section
-of the merge request. The form modal will also show a dropdown for changed pages
+of the merge request. The form modal also shows a dropdown for changed pages
if [route maps](#route-maps) are configured in the project.
![review button](img/review_button.png)
@@ -251,13 +251,13 @@ to replace those values at runtime when each review app is created:
`CI_MERGE_REQUEST_IID` variable. `CI_MERGE_REQUEST_IID` is available only if
[`only: [merge_requests]`](../merge_request_pipelines/index.md)
is used and the merge request is created.
-- `data-mr-url` is the URL of the GitLab instance and will be the same for all
+- `data-mr-url` is the URL of the GitLab instance and is the same for all
review apps.
- `data-project-path` is the project's path, which can be found by `CI_PROJECT_PATH`.
-- `data-require-auth` is optional for public projects but required for [private and internal ones](#authentication-for-visual-reviews). If this is set to `true`, the user will be required to enter their [personal access token](../../user/profile/personal_access_tokens.md) instead of their name and email.
+- `data-require-auth` is optional for public projects but required for [private and internal ones](#authentication-for-visual-reviews). If this is set to `true`, the user is required to enter their [personal access token](../../user/profile/personal_access_tokens.md) instead of their name and email.
- `id` is always `review-app-toolbar-script`, you don't need to change that.
- `src` is the source of the review toolbar script, which resides in the
- respective GitLab instance and will be the same for all review apps.
+ respective GitLab instance and is the same for all review apps.
For example, in a Ruby application with code hosted on in a project GitLab.com, you would need to have this script: