github actions stabilization (aka build failure shenanigans)

[thescientist13]

Type of Change

• New Feature Request
• Documentation / Website
• Improvement / Suggestion
• Bug
• Other (please clarify below)

Summary

Two new build errors have popped up in both our CI (Windows) and Master (Ubuntu) GitHub Actions :/

CI (Windows) - x2

The build step of the job is failing when building the website due to some file copying issue seemingly related to our polyfill-plugin? This also seems to cause the build to hang a stall out for ~ 40 minutes.

Details

UnhandledPromiseRejectionWarning: Error: EBUSY: resource busy or locked, copyfile

• https://github.com/ProjectEvergreen/greenwood/runs/3611389959
• https://github.com/ProjectEvergreen/greenwood/runs/3624628979

(node:2132) UnhandledPromiseRejectionWarning: Error: EBUSY: resource busy or locked, copyfile 'D:\a\greenwood\greenwood\node_modules\@webcomponents\webcomponentsjs\bundles\webcomponents-sd-ce-pf.js.map' -> 'D:\a\greenwood\greenwood\public\bundles\webcomponents-sd-ce-pf.js.map'
prerendering complete for page /about/features/.
prerendering complete for page /about/goals/.
(Use `node --trace-warnings ...` to show where the warning was created)
prerendering complete for page /docs/front-matter/.
(node:2132) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
prerendering complete for page /about/community/.
(node:2132) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Analysis

So what is interesting is that this is happening across different branches of work, respectively

• [DO NOT MERGE] Bug/issue 675 puppeteer declarative shadow dom support #726
• clean up test case #724

And only for Windows, though testing it on my Windows did highlight some instability as well.

  999 passing (5m)
  8 pending
  93 failing

  1) Develop Greenwood With:
       Default Greenwood Configuration and Workspace
         Running Smoke Tests: Default Greenwood Configuration and Workspace
           Serving Index (Home) page
             "before all" hook for "should start the server and return 200 status":
     Error: connect ECONNREFUSED 127.0.0.1:1984
      at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1146:16)

Maybe Some kind of [race condition / `async` shenanigans](https://github.com/ProjectEvergreen/greenwood/blob/master/packages/plugin-polyfills/src/index.js#L18) perhaps? 

### Master (Ubuntu) - x1

A bunch of the specs started failing (and likely cascading failures into one another) due to a connection error, seemingly an indicating a server didn't stop (in time)?
<img width="984" alt="Screen Shot 2021-09-17 at 12 03 47 PM" src="https://user-images.githubusercontent.com/895923/133894320-097aabe7-9bb9-4586-9c86-3a31a1c8b002.png">


#### Details
`Error: listen EADDRINUSE: address already in use :::1984`
- https://github.com/ProjectEvergreen/greenwood/runs/3624618801

```sh
 Serve Greenwood With: 
    Default Greenwood Configuration and Workspace
      Running Smoke Tests: Default Greenwood Configuration and Workspace
        Serving Index (Home) page
          1) "before all" hook for "should start the server and return 200 status"
      Serve command with dev proxy
        2) "before all" hook
        3) "before all" hook for "should return a 200 status"
    Build Greenwood With: 
    Develop Greenwood With: 
      Developement environment for a heme Pack
        Developement environment for a Theme Pack
-------------------------------------------------------
Welcome to Greenwood (v0.16.0-alpha.1) ♻️
-------------------------------------------------------

Running Greenwood with the build command.

Initializing project config
Initializing project workspace contexts
Generating graph of workspace files...

events.js:377
          4) "before all" hook in "Developement environment for a heme Pack"
      throw er; // Unhandled 'error' event
      Build Greenwood With: 
      ^
        Default Babel configuration

Error: listen EADDRINUSE: address already in use :::1984
    at Server.setupListenHandle [as _listen2] (net.js:1320:16)
    at listenInCluster (net.js:1368:12)
    at Server.listen (net.js:1454:7)
    at Application.listen (/home/runner/work/greenwood/greenwood/node_modules/koa/lib/application.js:82:19)
    at /home/runner/work/greenwood/greenwood/packages/cli/src/commands/build.js:1:6061
    at new Promise (<anonymous>)
    at /home/runner/work/greenwood/greenwood/packages/cli/src/commands/build.js:1:5938
Emitted 'error' event on Server instance at:
    at emitErrorNT (net.js:1347:8)
    at processTicksAndRejections (internal/process/task_queues.js:82:21) {
  code: 'EADDRINUSE',
  errno: -98,
  syscall: 'listen',
  address: '::',
  port: 1984
}

.. (etc)

Analysis

Maybe the timeout interval in our tests needs to be longer to allow more time for tests to run and shut down the dev servers from run to run?

Or maybe something would could eliminate entirely via #71

Thoughts / Next Steps

It looks like everything has been fine in Netlify and locally for the most part, but should do the following

1. Test build on Windows VM, verify NodeJS version (v14.17.0)
   • interestingly, running yarn clean && yarn build passed 5/5 times
   • running yarn test passed 3 / 5 times, failing a connection refused error

   TODO

2. Compare all .github workflows in the repo to make all configs are in sync - https://github.com/actions/setup-node#matrix-testing
   • looks like these could be cleaned up a bit
3. maybe it will help, but consistent use of localhost via 127.0.0.1 across specs / source code, ex.

   Started local development server at localhost:1984
   GraphQLServer started at http://localhost:4000/
   Prerendering pages at http://127.0.0.1:1984

4. Re-run master job to see if it was a fluke?