<!-- Implementation issues are used break-up a large piece of work into small, discrete tasks that can move independently through the build workflow steps. They're typically used to populate a Feature Epic. Once created, an implementation issue is usually refined in order to populate and review the implementation plan and weight. Example workflow: https://about.gitlab.com/handbook/engineering/development/threat-management/planning/diagram.html#plan --> ## Why are we doing this work <!-- A brief explanation of the why, not the what or how. Assume the reader doesn't know the background and won't have time to dig-up information from comment threads. --> Currently for a MR, after the pipeline for the MR completes, a security report summary is shown on the MR page: || |-| || We want to add descriptive information/error messages to give the user better info on what's going on with the security summary and steps they can take to fix any issues with it. ## Relevant links Mocks B5 - B6 * [B5. Use cases: Non-error states](https://gitlab.com/gitlab-org/gitlab/-/issues/12896/designs/b5-use_cases_non-error-states.png) * [B6. Use cases: Error States](https://gitlab.com/gitlab-org/gitlab/-/issues/12896/designs/b6-use-cases_error-states.png) <!-- Information that the developer might need to refer to when implementing the issue. - [Design Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>) - [Design 1](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>/designs/<image>.png) - [Design 2](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>/designs/<image>.png) - [Similar implementation](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/<id>) --> ## Non-functional requirements <!-- Add details for required items and delete others. --> - [ ] **Documentation:** will need to be updated to cover the new messages that can be displayed ## Decisions - [Hold off on implementing the `resolved` alert for now](#note_565144642). This has been extracted to https://gitlab.com/gitlab-org/gitlab/-/issues/329910. - [De-nest the message display logic](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20954#note_564335898) for showing the base report is out of date / the source branch is behind the target branch. - Implement the failed jobs alert as-is, using a [GraphQL query to determine if any failed](https://gitlab.com/gitlab-org/gitlab/-/issues/275818#failed-jobs-query). - [Keep using the existing `base_report_out_of_date`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20954#note_564335898) returned from the scanner comparison endpoints, rather than switching to the new `MergeRequest.securityReportsUpToDateOnTargetBranch` GraphQL field. - [Expose `securityReportsUpToDateOnTargetBranch` to the MR widget in order to display the widget in the case that scanners were enabled _after_ the source branch was created](#note_562802638). - [Keep using the existing `enabled_reports` field rather than the new `MergeRequest.hasSecurityReports` GraphQL field](#note_562802638). - [Keep using the existing `diverged_commits_count` field rather than the new `MergeRequest.divergedFromTargetBranch` GraphQL field](#note_562802638). - Improving/implementating loading states is tracked in https://gitlab.com/gitlab-org/gitlab/-/issues/287706. - [Improving the l18n/l10n strings](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/46167#note_445227230) will be handled in https://gitlab.com/gitlab-org/gitlab/-/issues/287706, since they are related to the loading state(s). ## Implementation plan (likely out of date, see https://gitlab.com/gitlab-org/gitlab/-/issues/267504#note_607944913) <!-- Steps and the parts of the code that will need to get updated. The plan can also call-out responsibilities for other team members or teams. --> Note that some of the unchecked items below have been drafted in a PoC MR https://gitlab.com/gitlab-org/gitlab/-/merge_requests/64608. ~frontend - One or more security jobs failed (see PoC MR https://gitlab.com/gitlab-org/gitlab/-/merge_requests/64608) - **The design/appearance of this alert is currently under discussion, and may still change. See [this thread](#note_596260647))**. - Design  - [ ] Expose/consume `failures_project_pipeline_path` for link to job failures - [ ] Add apollo query for [getting security jobs' statuses](https://gitlab.com/gitlab-org/gitlab/-/issues/275818#failed-jobs-query). If any job has `detailedStatus.text === 'failed'`, show the alert. - [ ] Probably need to add a new slot to `ReportSection` component between the `.media` element and before the `body` slot containing element to contain the alert - User's source branch is behind the target branch - [x] [De-nest the message display logic](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20954#note_564335898) for showing the base report is out of date / the source branch is behind the target branch. (see https://gitlab.com/gitlab-org/gitlab/-/merge_requests/64090) - User enabled security scanners after source branch was created (see PoC MR https://gitlab.com/gitlab-org/gitlab/-/merge_requests/64608) - [ ] Expose [`security_reports_up_to_date?`](https://gitlab.com/gitlab-org/gitlab/blob/b9fe40b05fae29b7280374665647bd94b8052858/ee/app/models/ee/merge_request.rb#L273) method on `MergeRequestPollWidgetEntity` - [ ] Render security widget if there are any `enabled_reports` _or_ if `security_reports_up_to_date?` is `false`. - [ ] Ensure widget displays message `Security scanning detected no results for the source branch only` and shows the `error` status rather than `success` status. Might require some Vuex work. <!-- Workflow and other relevant labels ~"group::" ~"Category:" ~"GitLab Ultimate" --> <!-- Other settings you might want to include when creating the issue. -->