feat: re-introduce comment-based trigger for Chromatic

[dcshzj]

Problem

Chromatic snapshots are expensive and we should have a way to get a snapshot only when we really need one.

Solution

Breaking Changes

• Yes - this PR contains breaking changes
• No - this PR is backwards compatible

Features:

• A second attempt of triggering Chromatic snapshots via a PR comment. Here's what changed from previously:
  • A new branchName configuration has been added. This is needed to let Chromatic be aware of where the snapshot is coming from. Without this configuration, Chromatic will pull from the GITHUB_REF environment variable, which is always develop when on the issue_comment workflow. This causes Chromatic to constantly rebuild the develop branch and causing our baselines to always reset.
  • A new autoAcceptChanges configuration has been added. This is needed so that the baseline (which should, in theory, be the develop branch) is up-to-date, as Chromatic treats the latest accepted ancestor build as the baseline to compare pull request changes against. This is done together with the push event to the develop branch, which will generate a new Chromatic snapshot that Chromatic will automatically mark as accepted.

Notes:

• Changes were tested earlier on a personal repository and the Chromatic build history is here (notice the build ancestors for each build).
• However, Chromatic builds work in mysterious ways which is very difficult to test. In the worst case if this does not work, we can just follow how FormSG does it.

You tell me that you can only test after this is merged, how am I going to review this?

I hear your concerns. This was what I did to test my hypothesis:

• Visit the test repository that I created to simulate Chromatic builds and the Chromatic build history.
• Step through the changes made (using the test-1, test-2, test-3, test-4 and test-5 branches, along with their associated PRs).
• Step through the Chromatic builds made (including the ones for develop).
• Analyse the ancestor build(s) that Chromatic has chosen. The builds chosen should make sense (baseline should be develop as much as possible, or the parent commit of the same branch).
• Finally, check that the syntax of the workflow file is correct.

If you are interested, the full documentation of how Chromatic calculates the ancestor builds is available.

Tests

Developer experience changes, no user-facing changes. Testing can unfortunately only be done once it is merged.

Deploy Notes

None

[seaerchin]

Lgtm, thanks for the comprehensive write up!

[dcshzj]

Going to merge this now, we are not urgently using Chromatic so it would give me sufficient time to fine-tune this.