Support turbosnap for pull_request workflow trigger

[quantizor]

The pull_request event object does contain the sha for the base commit that triggered the workflow run. Can't you just use github.event.pull_request.base.sha to do your historical calculations and thus be able to support that trigger without further upset?

As an aside, I noticed the action directly references the github event json and has a switch statement to fork the handling based on workflow trigger. It'd be nice if the action leveraged the typical github environment variables instead so it's easier to override from the downstream consumer's perspective.

[quantizor]

The reason why push trigger is undesirable is it only operates on the most recent commit without taking the context of the PR into account. For instance, for a PR with multiple commits, the last commit might not have a change that triggers chromatic to run (based on paths configuration in the workflow.) That means if we set Chromatic's github check as required, for PRs that modify that part of the codebase but the last commit is a misc change the PR becomes unmergable without admin override.

[abbudao]

I suffer the same problem with my Nx setup. This Chromatic limitation is very frustrating and forces me to run my entire CI on push instead of pull_request. Would you consider supporting pull_request triggers?

[fpaz]

We're now experiencing the same frustration as above using nx in a large mono-repo. Please support pull_request trigger.