### Problem to solve <!-- What problem do we solve? --> The Code Climate report in the MR view is missing if there is no report to compare the current artifact to. <p> <details> <summary>This was initially written up as a bug from @k.boese which is preserved here.</summary> ### Summary The code climate report from pipelines does not longer show up in merge requests (for a few days for now) ### Steps to reproduce Any merge request triggers a code climate check via template. The artifact exported by this job should display a code climate report on the MR. Sample MR which should show climate report: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/15794 - but its missing ### Example Project gitlab-ee ### What is the current *bug* behavior? No climate report displayed ### What is the expected *correct* behavior? Climate report displayed ### Relevant logs and/or screenshots - ### Output of checks This bug happens on GitLab.com ### Stuff * The report is uploaded as artifact * Climate updated the images this days * We are using an own runner for climate to not use gitlab runner time, but our job worked until recently. As gitlabs climate reports are missing as well i dont think its an issue on our runners site </details> </p> ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) * [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst) Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> When researching this bug we found that when an artifact is expired it can't be used for comparison, thus the missing code climate report. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> The outcome we want for users is to know why a code quality score is not present when they expect it to be. When the `base_path` is missing, it could be one of two things: 1. This is the first time code quality is being introduced to the project so the `code_quality` job has never been run on the target branch, usually `master`. The MR has to be merged first for succeeding MRs to show the widget. 2. The MR's `base_pipeline`'s report artifact has already expired and there are more recent commits to `master` having the updated report. The MR must be rebased on master. See https://gitlab.com/gitlab-org/gitlab/issues/14033#note_244402302 for more info. It won't be possible to tell which case is true because `base_path` will just be `null` for both, so we have to craft a message that can inform the user about these 2 possible cases. Once we have the message, show it on the widget's section whenever `base_path` is missing. Right now we just don't show the widget at all if `base_path` is missing. ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?--> ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> The docs for [code quality](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html) should be updated to contain this information as well. ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further help: https://about.gitlab.com/handbook/engineering/quality/test-engineering/ --> * We need to test against some non-standard GitLab Flow cases, like the example in the notes [below](https://gitlab.com/gitlab-org/gitlab/issues/14033#note_244402302). ### What does success look like, and how can we measure that? <!-- 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. --> * Users who can make use of code quality reports but do not see one in the MR widget always have direction on how to get a report on their next MR. Acceptance Criteria * Users get clear information in the about why a code quality score is not present and how to resolve the issue. * Readers of code quality documentation will know when to expect/not expect a code quality score based on reading the docs. ### What is the type of buyer? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ### Links / references /label ~feature