[Hold] Add 'rwjs/redwood' Repo CI via GH Actions: Build, Lint, and Jest

[thedavidprice]

Closes #105

[thedavidprice]

Whelp... it's a start I guess. TBD

[thedavidprice]

In future, will need to implement caching to improve performance:

• https://github.com/actions/cache
• https://help.github.com/en/actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows

Ran into issues with GH Action caching not yet possible with yarn v1 workspaces. Conceivably could config the Action to run individually on each package (check cache, install, build, test), but that seems like a pain for now.

Related:

• GH Actions not able to cache multiple workspace paths: /Cache multiple paths actions/cache#16
  • and related PR to add the multi-path support: Introduce paths input to support multiple cache paths actions/cache#180
• Node Docker Container support for Yarn2: Yarn 2 support nodejs/docker-node#1180
• Found Actions specific to Yarn 2 here: sergioramos/yarn-actions
  • which I found here: sdras/awesome-actions

[thedavidprice]

Aside from the fact the few test we have are failing 😉, this is now working for tests on Node 10 latest (Dubnium) and Node 12 latest (Erbium). For both environments, the action runs yarn build and yarn test.

It’s slow without caching. And without test coverage might not be all that useful yet. But ready to go when we are.

If we do decide to merge, we should:

• fix current failing tests
• take a stab at any mission critical tests (maybe)

[thedavidprice]

Notes for possible improvements:

• employ something like lerna changed to build against modified packages only (need to choose what our reference will be… last npm release is more than needed but might be good easy first step. ideally just new commits.)
• separate into two Actions: 1) build and 2) test

Another Action workflow we might get easily is opening a PR for all our other projects needing to update package versions.

[thedavidprice]

@peterp Take a look at the build errors I’m now getting running against latest master. Looks like failing on cli/… possibly something to do with permissions on the GH Actions container? (Actions are painful to debug… so looking for some intuition before I dive in.)

[thedavidprice]

Fixed an error caused by directory name mismatch between uppercase cli/src/commands/Generators/ and actual ..generators/. Also changed ..dbGenerators/ to db_generators. Then adjusted import statements accordingly.

Builds are now passing.

Added Linting.

Linting and Jest are running but failing.

[thedavidprice]

yarn lint is generating the following error repeated about 10x:

[eslint-import-resolver-babel-module] TypeError: Cannot read property 'plugins' of null
    at getPlugins (/Users/price/Repos/redwoodjs-redwood/node_modules/eslint-import-resolver-babel-module/lib/index.js:23:19)
    at getPluginOptions (/Users/price/Repos/redwoodjs-redwood/node_modules/eslint-import-resolver-babel-module/lib/index.js:35:21)
    at Object.exports.resolve (/Users/price/Repos/redwoodjs-redwood/node_modules/eslint-import-resolver-babel-module/lib/index.js:94:27)
    at v2 (/Users/price/Repos/redwoodjs-redwood/node_modules/eslint-module-utils/resolve.js:117:23)
    at withResolver (/Users/price/Repos/redwoodjs-redwood/node_modules/eslint-module-utils/resolve.js:122:16)
    at fullResolve (/Users/price/Repos/redwoodjs-redwood/node_modules/eslint-module-utils/resolve.js:139:22)
    at relative (/Users/price/Repos/redwoodjs-redwood/node_modules/eslint-module-utils/resolve.js:84:10)
    at resolve (/Users/price/Repos/redwoodjs-redwood/node_modules/eslint-module-utils/resolve.js:220:12)
    at resolveImportType (/Users/price/Repos/redwoodjs-redwood/node_modules/eslint-plugin-import/lib/core/importType.js:148:65)
    at computeRank (/Users/price/Repos/redwoodjs-redwood/node_modules/eslint-plugin-import/lib/rules/order.js:317:44)
See: https://github.com/tleunen/eslint-import-resolver-babel-module/pull/34

I took a look at tleunen/eslint-import-resolver-babel-module#34 which basically says the warning/error is just a wrapper around Babel do indicate something went wrong with the Babel config. In our case the error TypeError: Cannot read property 'plugins' of null is coming from Babel. I was unable to diagnose so far.

[peterp]

I personally don't like using snake_case file naming conventions in javascript projects. The reason for this is that we don't generally name our variables or functions in snake case and I try to name the file the same as the main exported function.

The way that I change cases with git is to use two commits.

git mv Generate xGenerate
git commit -am 'Renaming Generate -> generate part 1.'
git mv xGenerate generate
git commit -am 'Renaming Generate -> generate part 2.'

I think we should open this for discussion and figure out what standard we would like to apply to the project as a whole.

[thedavidprice]

closing this in favor of #257

Will be creating separate issues for:

1. next steps to enhance CI
2. linter warnings related to bable config error