Skip to content

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:

image

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 
/blog/categories
http://www.example.com/blob/categories
  • Dropdown features changed url and changed 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

Artboard_2

Artboard

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.

Links / references

Edited by Jason Yavorsky