Link directly to changed pages in Review App from MR Widget
Problem to solve
The default review app link is often not handy as it is not context aware.
Further details
Usecase: When I write a blog post I want to preview the blog post, not the whole website
Proposal
As a user, when I change one page on the static website, the review app should link to that page instead of (or in addition to) the root of the server.
Look at the mapped paths, and only show if it ends in no extension (like our blogpost) or .html
. That would take care of html.md.erb
. Images will of course always keep their extension, so would be ignored. It would pretty accurately identify web pages.
This could look something like this:
Solution
- Split button dropdown
- Dropdown menu options trigger in two clicks (click 1: open dropdown, click 2: select action)
- Default option split dropdown always defaults to the default environment url and states
View app
as it already does- changed url:
http://www.example.com/blob/categories
- changed url - no host:
/blog/categories
- changed url:
/blog/categories
http://www.example.com/blob/categories
- Dropdown features
changed url
andchanged url - no host
for relevant changes - Search included for if there are many relevant changes
- Deleted pages are not shown
- Use one of the predefined dropdown widths that comes closest to
560px
- Urls should be ellipsed (at the beginning) when too long instead of wrapping
Note: The dropdown width should match what is detailed in the specs (400px): https://gitlab-org.gitlab.io/gitlab-design/hosted/design-gitlab-specs/dropdown-spec-previews/
backend changes
As decided in https://gitlab.com/gitlab-org/release/framework/issues/23 this feature will be developed under a feature flag named ci_environments_status_changes
.
Today the deployment widget is populated from the following API
# GET http://localhost:3000/root/test-pages/merge_requests/5/ci_environments_status
[
{
"id": 40,
"name": "review/root-master-patch-91341",
"url": "/root/test-pages/environments/40",
"metrics_url": null,
"metrics_monitoring_url": "/root/test-pages/environments/40/metrics",
"stop_url": "/root/test-pages/environments/40/stop",
"external_url": "http://root-master-patch-91341.volatile-watch.surge.sh",
"external_url_formatted": "root-master-patch-91341.volatile-watch.surge.sh",
"deployed_at": "2018-10-12T13:08:21.839Z",
"deployed_at_formatted": "Oct 12, 2018 1:08pm"
}
]
We will add a new key changed
: an array with path
and external_url
of the affected pages.
This includes every file added, moved or modified that has a relative path, after the URL transformation, that has no extension or .html
extension.
# GET http://localhost:3000/root/test-pages/merge_requests/5/ci_environments_status
[
{
"id": 40,
"name": "review/root-master-patch-91341",
"url": "/root/test-pages/environments/40",
"metrics_url": null,
"metrics_monitoring_url": "/root/test-pages/environments/40/metrics",
"stop_url": "/root/test-pages/environments/40/stop",
"external_url": "http://root-master-patch-91341.volatile-watch.surge.sh",
"external_url_formatted": "root-master-patch-91341.volatile-watch.surge.sh",
"deployed_at": "2018-10-12T13:08:21.839Z",
"deployed_at_formatted": "Oct 12, 2018 1:08pm",
"changes": [
{
path: "index.html",
external_url: "http://root-master-patch-91341.volatile-watch.surge.sh/index.html"
},
{
path: "imgs/gallery.html",
external_url: "http://root-master-patch-91341.volatile-watch.surge.sh/imgs/gallery.html"
},
{
path: "about/",
external_url: "http://root-master-patch-91341.volatile-watch.surge.sh/about/"
}
]
}
]
What does success look like, and how can we measure that?
The user is able to directly open the url with its contents changed by the current merge request.