<!-- The first four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Problem to solve As a developer reviewing an MR with failing tests, I want to be able to click a link to a file from the MR widget, so I can quickly resolve broken tests and get a green pipeline. <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> ### Intended users * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) ### User experience goal The user should be able to use the MR UI to click through the widget to a failed test so they don't have to dig through the File Repository view. <!-- What is the single user experience workflow this problem addresses? For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>" https://about.gitlab.com/handbook/engineering/ux/ux-research-training/user-story-mapping/ --> ### Proposal * Add the filename to the modal used on the Test Summary Report (see below) * Make the filename a link to the test file in the repository (as was done for the [Unit Test report](https://gitlab.com/gitlab-org/gitlab/-/issues/267344)] * Clicking should open a new window/tab to the file <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> ### Further details This change will make the interfaces consistent in behavior so users with and without MRs can both quickly get from a failed test notice to the test file itself. ### Documentation None. ### What does success look like, and how can we measure that? We'd expect that this will increase engagement with the widget by 5% above normal growth within 90 days of launch as measured by the [interaction with the MR widget](https://gitlab.com/gitlab-org/gitlab/-/issues/235524). <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### What is the type of buyer? The Developer cares most about this as it improves their own workflow. ### Is this a cross-stage feature? Yes with ~"devops::create" as it's on the MR page. ### Links / references <p> <summary><h3>Initial proposal</h3></summary> <details> ### Background This JUnit XML epic https://gitlab.com/groups/gitlab-org/-/epics/187 contains the priority of iterations for the MR widget and CI view. ### Proposal * For each failed test display in the MR widget, we should allow users to hyperlink from the MR widget to the specific file/line in the JUnit testfile where the test failure occurred. </details> </p>