feat(ci): add a validation step for starters

[DSchau]

Description

This PR will (start) to add some increased validation and checks for starters. In particular, it will generate a yarn.lock file in each starter (and add this to the read-only clone), as well as run the build script to validate a successful build.

During a pull request, it will:

• Run npm install
• Run npm run build

This will catch issues with a dependency change causing a failure, but it will not (currently) catch something like a failure introduced in the current changes in the PR (e.g. a change to Gatsby like in #10593). Fixing both of these are worth exploring, I just don't want to slow down the build too much.

During a merge to master, it will:

• Run npm install
• Run npm run build
• Run yarn import (generate a yarn.lock file based on the contents of package-lock.json)
• Sync to gatsbyjs/gatsby-starter-NAME

My main concern with the merge to master is that it's possible to fail and not know it fails. We do merge to master enough that it's not a huge concern and we'd catch it the next pull request, but worth noting.

Related Issues

Begins to address #10607

[DSchau]

Also - I want to think more on this approach.

This doesn’t seem extremely scalable, and I want to avoid having to resort to editing shell scripts and adding additional (possibly slow) checks for every new functionality we want to validate.

It’ll work—but I’d like to see if there’s something cleaner and perhaps simpler.

[DSchau]

So after thinking more on this, it may make sense to just make starters part of lerna/workspaces—then we can run whatever arbitrary tasks we want in the repo pretty cleanly.

@pieh what this PR has works, but could possibly be improved. What do you think?

[pieh]

I think this looks good to test. One thing that potentially worries me is the lock generation: If I read this right - it will (re)generate lock files on master commits. There is slight problem - lerna pushes publish commits before it push packages to npm registry, so we might be "version" behind with the lock files if we install deps before publish is complete?

[DSchau]

@pieh your comment there is if we swap to the lerna/workspaces approach, correct? As it works now, we're just basing the yarn.lock generation off of what exists in package-lock.json (which currently isn't auto-generated whatsoever, unfortunately).

[pieh]

Looks good, let's take it for test drive