Add UI support for displaying merge requests deployed in a deployment - Merge Request View
In !18755 (merged) we are adding backend support for tracking merge requests deployed using GitLab environments and deployments. In #35739 (closed) we discuss adding API support for this data. Similar to this issue we should add UI support for this data. There are two cases we have:
- When viewing a merge request we want to see when a merge request was first deployed to an environment, grouped per environment. We can reuse the existing deployments widget for this, and just change what data it uses.
- #36406 : When viewing a deployment we want to see the merge requests that were included. While we may not need it immediately, we are definitely going to need support for filtering these merge requests (e.g. by author). Ideally we display the merge requests the same way as we do on the merge requests dashboard and the project merge requests index page.
Note that we should not start adding the UI before the API, as ideally we use this API for the UI; or at least reuse the underlying code.
As a user, I want to see the first deployment for my merge request in the MR widget, so I can know when it made it to staging/production/etc.
- To clarify that we only show the first deployment per environment (which in most cases will be the same as all deployments of that MR to an environment), we add some kind of
?icon with a tooltip on hover.
- We continue to display the data on a merge request exactly the same as we do now, only the means of getting that data changes.
- Given an environment, in the MR widget we would only display the first deployment since we want to know when our MR first made it to staging/production/etc. Any deployments that follow it don't matter that much, so we don't need to display them.
- All action items (buttons) for a deployment in the MR widget stay as-is (View app, review, stop latest deployment).
A merge request can only be deployed to the same environment multiple times if it is reverted and later that revert is reverted again (using a merge request). This is rare, and even when it happens that first deployment is still the most important.