Manually set baseline build commit signature

[jmuzina]

Done

#5300 updated the Percy workflow to merge main into a PR before it is tested, but our dual-workflow approach seems to throw a wrench in Percy's baseline build detection: even though the files being tested are a merge of main with a PR, Percy may select a baseline build that is older than the current baseline build, causing false positive test results.

This occurred in #5338 (PR branch was cut from main before merge of #5270). However the Percy build used a baseline build from before the merge of #5270), causing the tree list snapshots to incorrectly appear as new. It appears Percy needs to be manually instructed to use the latest main commit for this two-workflow approach to not have hiccups with merge conflicts. This can be done with environment variables.

This should mean that you only need to merge/rebase branches for Percy tests where source merge conflicts exist.

QA

• Verify my fork's main branch is the same as Vanilla's main branch, but with this PR's commit added.
• Verify my test PR is identical in contents to Make separator styling consistent #5338
• Verify that the Percy build for my test PR has only the expected changes from Make separator styling consistent #5338 , and has no unexpected "New snapshot" results for the tree list snapshots.
• Verify that baseline builds still show the visual changes between the previous and new baseline build, and the head commit and base commit on the baseline build details are not the same.

Check if PR is ready for release

If this PR contains Vanilla SCSS code changes, it should contain the following changes to make sure it's ready for the release:

• PR should have one of the following labels to automatically categorise it in release notes:
  • Feature 🎁, Breaking Change 💣, Bug 🐛, Documentation 📝, Maintenance 🔨.
• Vanilla version in package.json should be updated relative to the most recent release, following semver convention:
  • if CSS class names are not changed it can be bugfix release (x.x.X)
  • if CSS class names are changed/added/removed it should be minor version (x.X.0)
  • see the wiki for more details
• Any changes to component class names (new patterns, variants, removed or added features) should be listed on the what's new page.

[webteam-app]

Demo

Jenkins

demos.haus