<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=24004) </details> <!--IssueSummary end--> From > There is no unit or integration test that would have caught this issue. I'm not sure that I made this clear above, but the problem is that the cache persists across upgrades. So a single version of GitLab cannot test itself against another version (prior or subsequent). gitlab-qa can do this, but it's fiddly to orchestrate and I think a better solution might be to just make this caching not behave that way > Yes, such test would require: > * Spinning up a GitLab instance > * Have a test that creates a MR > * Update the instance's version > * Have another test that checks the diff formatting of the MR created before updating > Note that we already test instance update (from latest or the specific commit udner test to nightly), e.g. https://gitlab.com/gitlab-org/gitlab-qa/-/jobs/93066015 but we currently don't run tests on resources created before the version update (i.e. we always create new resources).