Scope pull request workflows to paths

[paulrobertlloyd]

Currently, visual regression tests are run when any file changes in a pull request. Should you make a tiny change to any file in the rep, such as package.json or a configuration file, it’ll take ~3.45mins to run visual regression tests. Changes outside of components get needlessly tested, but more importantly, untold resources are consumed while this task works away on a remote server somewhere.

This PR breaks out the previous pull-request.yml workflow into 3 separate workflows:

• analyse.yml - Perform static analyse if any file has changed
• lint.yml - Check code style if any file has changed (note that linters configured to only examine certain files within packages/components and /dist/app/components folders, arguably JS outside of packages/components should be linted, too)
• test.yml - Test JavaScript and perform visual regression tests only if a file has been changed in the packages, app or test folders. This is the change that should hopefully reduce the number of times these tests are run, notably when dependency updates are made to package.json and package-lock.json.

Now uses workflow action to check for changed files that are actually included in respective test tasks before running them.

[paulrobertlloyd]

Using tj-actions/changed-files action, we can test for changed files, and only continue to run workflows if a subset of files has changed.

I tested changing the HTML in a component, and the visual regression tests ran and correctly failed (after 3 minutes):

I reverted that change, and that test completed in only 24 seconds:

Using this action, we could revert to having all pull request workflows in one file. @frankieroberto what do you think? One file, or many?

[frankieroberto]

@paulrobertlloyd stick with one file for now (easier to review the diff)?

Given that most of the repo is in scope for possible changes which affect the tests, I slightly wonder useful it’ll be, but it would be nice to have speedier ✅ on PRs which just affect the README or whatever.

[paulrobertlloyd]

@frankieroberto Removed the (mostly) duplicate test run here, though potentially given concurrent tests, you’d want this workflow to fail early if there’s a failing test before running expensive visual regression tests?