Adding initial Github Actions setup

[ringods]

Closes #1185

Summary of changes:

• Added the basic setup to run the test script via Yarn.

For reference of viewers later on:

• Github Actions runners have a lot of software pre-installed.

[ringods]

@sghoweri @bmuenzenmeyer

While introducing Github actions, I looked in one package.json file for the engines setting. I found ">=10.0" in that file. I configured the Github Actions runner to use NodeJS 10.x, but the build fails because the following 2 packages requiring NodeJS 12:

• engine-handlebars
• development-edition-engine-handlebars.

Would it be OK to set the engines section to ">=12.0" in every package.json file of the monorepo, document this minimum version in the installation section and update my Github Actions config to use NodeJS 12?

[bmuenzenmeyer]

Would it be OK to set the engines section to ">=12.0" in every package.json file of the monorepo, document this minimum version in the installation section and update my Github Actions config to use NodeJS 12?

I am fine with that yes. My guiding light is the top-level .nvmrc file. https://github.com/pattern-lab/patternlab-node/blob/dev/.nvmrc

it looks like the README still says 6 too, 🤣

[coveralls]

Coverage remained the same at 73.388% when pulling db86acb on feature/github-actions into 54f1bb4 on dev.

[bmuenzenmeyer]

@sghoweri is the CONTRIBUTING GUIDE in the uikit still relevant?

[sghoweri]

@sghoweri is the CONTRIBUTING GUIDE in the uikit still relevant?

@bmuenzenmeyer Unfortunately not. I'm good with nuking it and starting from scratch

[sghoweri]

Would it be OK to set the engines section to ">=12.0" in every package.json file of the monorepo, document this minimum version in the installation section and update my Github Actions config to use NodeJS 12?

@ringods I'm 100% good with requiring a minimum of Node v12 or higher. Big thumbs up from me on that!

[sghoweri]

Overall I'm good with moving forward with all of this.

RE Github Actions, I'm totally open to trying it out here (I've tried it out a few times actually) however I wouldn't recommend nixing Travis until we're certain we're actually getting something out of switching (vs same build times and no major improvements otherwise).

Definitely worth giving it a try! 👍

[bmuenzenmeyer]

this run (sample size of 1): GH Actions were 25 seconds faster - though I'd have to look closer at whether or not coveralls is contributing to time in Travis.

[ringods]

I suggest to leave Github Actions and Travis running side by side for a while.

@bmuenzenmeyer not only look at the runtime (run start -> run end), but at the total lead time (git push -> run end). My experience is that Travis could take a while before the run sometimes starts. This is not reported as part of the runtime in the respective web portals.

As an example, for the last run (your sample size of 1), I compared the Github actions start time to the Travis start time:

• Github Actions: in the black console part, click on the 3 dots in the upper right and select Show timestamps, then expand the first block Setup job. I record the first date listed: Tue, 05 May 2020 14:08:52 GMT
• Travis CI raw output: line 9 shows the first time in epoch style: start=1588687743792683790. Converting this to regular datetime gives: Tuesday, 5 May 2020 14:09:03.792 GMT

So on this sample size, Travis was not only 25 seconds slower, it also started 11 seconds later. On other projects, I experienced this start delay to add up to 1.5 minutes.

Nevertheless, let's get this PR merged! 😉