@@ -416,81 +416,15 @@ and/or `production`) you can see this information in the merge request itself.
### Go directly from source files to public pages on the environment
> Introduced in GitLab 8.17. In GitLab 11.5 the file links
are surfaced to the merge request widget.
You can specify a Route Map to get GitLab to show **View on ...**
buttons to go directly from a file to that file's representation on the
[deployed website via Review Apps](review_apps/index.md).
To get this to work, you need to tell GitLab how the paths of files in your repository map to paths of pages on your website, using a Route Map.
A Route Map is a file inside the repository at `.gitlab/route-map.yml`, which contains a YAML array that maps `source` paths (in the repository) to `public` paths (on the website).
Below is an example of a route map for [Middleman](https://middlemanapp.com) static websites
like <https://gitlab.com/gitlab-com/www-gitlab-com>:
Mappings are defined as entries in the root YAML array, and are identified by a `-` prefix. Within an entry, we have a hash map with two keys:
-`source`
- a string, starting and ending with `'`, for an exact match
- a regular expression, starting and ending with `/`, for a pattern match
- The regular expression needs to match the entire source path - `^` and `$` anchors are implied.
- Can include capture groups denoted by `()` that can be referred to in the `public` path.
- Slashes (`/`) can, but don't have to, be escaped as `\/`.
- Literal periods (`.`) should be escaped as `\.`.
-`public`
- a string, starting and ending with `'`.
- Can include `\N` expressions to refer to capture groups in the `source` regular expression in order of their occurrence, starting with `\1`.
The public path for a source path is determined by finding the first `source` expression that matches it, and returning the corresponding `public` path, replacing the `\N` expressions with the values of the `()` capture groups if appropriate.
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 `index.html.haml`.
---
Once you have the route mapping set up, it will be exposed in a few places:
- In the merge request widget. The **View app** button will take you to the
environment URL you have set up in `.gitlab-ci.yml`. The dropdown will render
the first 5 matched items from the route map, but you can filter them if more
than 5 are available.
- In the diff for a merge request, comparison, or commit.
- In the blob file view.
 |
---
We now have a full development cycle, where our app is tested, built, deployed
as a Review app, deployed to a staging server once the merge request is merged,
and finally manually deployed to the production server. What we just described
is a single workflow, but imagine tens of developers working on a project
at the same time. They each push to their branches, and dynamic environments are
created all the time. In that case, we probably need to do some clean up. Read
With GitLab's [Route Maps](review_apps/index.md#route-maps) you can go directly
from source files to public pages on the environment set for Review Apps.
From then on, you have a full development cycle, where your app is tested, built, deployed
as a Review App, deployed to a staging server once the merge request is merged,
and finally manually deployed to the production server. This is a simple workflow,
but when you have multiple developers working on a project
at the same time, each of them pushing to their own branches, dynamic environments are
created all the time. In which case, you probably want to do some clean up. Read
