chore: add conditional check to preview release

[caseyisonit]

Description

This adds a conditional check to the preview-release workflow to only run on commit types feat,fix, or !:. The !: will capture any breaking change.

Motivation and context

• Reduce the number of preview releases published
• Only release functional testable code

Related issue(s)

• relates to PR chore: update preview release workflow to use snapshots #5365

Author's checklist

• I have read the CONTRIBUTING and PULL_REQUESTS documents.
• I have reviewed at the Accessibility Practices for this feature, see: Aria Practices
• I have added automated tests to cover my changes.
• I have included a well-written changeset if my change needs to be published.
• I have included updated documentation if my change required it.

---

Reviewer's checklist

• The conditional logic covers all semver edge cases that should release a preview version

[changeset-bot]

⚠️ No Changeset found

Latest commit: 1ddc96e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[caseyisonit]

using the : and ( ensures it is a commit type and not just a random word in the message

[github-actions]

Branch preview

• Documentation Site
• Storybook

Review the following VRT differences

When a visual regression test fails (or has previously failed while working on this branch), its results can be found in the following URLs:

• Spectrum | Light | Medium | LTR
• Spectrum | Dark | Large | RTL
• Express | Light | Medium | LTR
• Express | Dark | Large | RTL
• Spectrum-two | Light | Medium | LTR
• Spectrum-two | Dark | Large | RTL
• High Contrast Mode | Medium | LTR

If the changes are expected, update the current_golden_images_cache hash in the circleci config to accept the new images. Instructions are included in that file.
If the changes are unexpected, you can investigate the cause of the differences and update the code accordingly.

[nikkimk]

Lawless genius twirls mustache (LGTM)

[github-actions]

Tachometer results

Currently, no packages are changed by this PR...

[graynorton]

This looks like it will work, and I'm not necessarily opposed to going with this approach, but it bothers me a little bit to be relying on conventional commits for the publish-or-not logic, since we have moved in the direction of having Changesets be our source of truth for representing release-worthy changes.

What if, instead of conditionalizing the logic inside the job and inspecting commits, we were to only run the job when a push to main includes changes beneath the .changesets directory, something like this:

on:
  push:
    branches:
      - main
    paths:
      - '.changesets/**'

I think we could also add workflow_dispatch: to the on: block if we wanted to allow manually triggering the action from the GitHub UI.

[caseyisonit]

I think we could also add workflow_dispatch: to the on: block if we wanted to allow manually triggering the action from the GitHub UI.

we provide the changsets-snapshot-publish command for this use case since there wouldn't be a git sha associated from a workflow_dispatch

[graynorton]

we provide the changsets-snapshot-publish command for this use case since there wouldn't be a git sha associated from a workflow_dispatch

Ah, I hadn't thought about the missing sha issue!

The use case I had in mind was not an one-off snapshot release (which I agree changesets-snapshot-publish covers), but one where something had gone wrong and an automated preview build had been skipped or failed, and we wanted to essentially say "make an official preview release, but trust me and skip the changesets check". In this case, I imagined that the sha from the HEAD of main would be used, but I didn't think about where it would come from.

Anyway, it may be that we don't need to worry about that case.

[graynorton]

Approved, so we can get this merged. We'll follow up later to explore the possibility of using a Changesets-based trigger, as discussed here.