E2E testing isn't working for PR #5152 failing due to randomized commit ID

[rowanfr]

Description

The bug repeatedly cause E2E failures in testing.

Steps to reproduce

This is reproduced every time a commit is pushed in mermaid during the E2E cypress testing in cypress/integration/rendering/gitGraph.spec.js

Screenshots

![Git-Graph-diagram-47-should-render-GitGraph-with-merge-back-and-merge-forward--Vertical-Branch diff](https://github.c

om/mermaid-js/mermaid/assets/28838223/a47fcc20-4c18-46e2-9b47-d04825775387)

Code Sample

it('46: should render GitGraph with merge back and merge forward', () => {
    imgSnapshotTest(
      `gitGraph LR:
      commit
      branch branch-A
      branch branch-B
      commit
      checkout branch-A
      merge branch-B
      checkout branch-B
      merge branch-A
      `,
      { gitGraph: { parallelCommits: true } }
    );

Setup

• Mermaid version: Latest, 1857eb1
• Browser and Version: Chrome

Suggested Solutions

Add specific commit id's similar to the other git graph tests for consistency.

Additionally we should likely check-in the test images in the actual repository itself to have some base truth for testing that is modifiable rather than relying upon the most recently cached image (as best as I understand the E2E testing). Currently because of that this test will fail despite modification to it to resolve random titles as the previous image is cached leading to either a desire to change the name of the tests or merge without successful E2E testing, both of which are bandaid solutions to a lack of modifiable base truth for E2E testing.

[sidharthv96]

Additionally we should likely check-in the test images in the actual repository itself to have some base truth for testing that is modifiable rather than relying upon the most recently cached image (as best as I understand the E2E testing)

We have an applitools test suite which we use before every release. But they have a limited volume for OSS projects and we don't want to run it on every test. The current option is a tradeoff so that we have some checks on all PRs, rather than get multiple failures right before we want to make a release. In this case, we'll know what's failing before merging a PR.

I understand this is not the best scenario, and is a bandaid, but it prevents a bigger pain for maintainers down the line.
We're very much open for better solutions :)

[rowanfr]

@sidharthv96 Thank you for explaining the reasoning behind why this is the current circumstance, it makes far more sense knowing that. While I'd love to provide an easier solution, I think the one currently being used was correctly identified as the most reasonable one for maintainers presently