Run chromatic directly on dependabot PRs

[jamie-lynch]

What is the purpose of this change?

As of March 2021, workflows triggered by a push event don't have access to GitHub secrets, if that event originates from a fork of the repo. As a result, PRs raised by Dependabot are not able to trigger a Chromatic run.

In #1112 we introduced a workaround:

Here I am creating a special workflow that completes successfully if the user raising the PR is Dependabot.

When this completes, the Chromatic workflow is triggered by the workflow_run event. Workflows triggered by this event > have access to secrets, so can successfully run Chromatic.

Recently we discovered that the chromatic workflow was running multiple times against the same commit for a dependabot PR, increasing the number of snapshots and therefore the bill for chromatic.

#1177 updated the workflow to allow chromatic to be triggered by the workflow_dispatch event, i.e. manually. The hope was that this would let us manually run the step for dependabot PRs just before they were merged. Unfortunately, an error occurred when running the workflow manually.

This PR reverts those changes and returns us to the situation where chromatic will run automatically on a dependabot PR but fail due to a lack of token. Whilst this is not ideal, it is possible to manually rerun the workflow successfully. This means that we retain chromatic checks on dependabot PRs but only have to run the workflow once, reducing the number of snapshots consumer.

[jamie-lynch]

cc @jfsoul

Trying out a return to manual reruns, not ideal developer experience but we managed like this for a few months without great difficultly so (I think) this is a reasonable compromise until we can think of something better

[jfsoul]

Thanks @jamie-lynch - I can't approve this on behalf of the team - it's your workflow and your call - but it seems sensible to me!

On the multiple builds for the same commit - I had a suspicion after looking at those that it may be a red herring. While the GHA UI identifies the commit as the same:

When you actually look at the commits that Chromatic uses, they are indeed different (and I think valid commits to build for):

I wondered whether this is perhaps more to do with the way the actions/checkout works for workflows triggered by workflow_run? (assuming this is what github use for the actions UI to identify commit ID)