Open timofeysie opened 4 years ago
The --watchAll=false
is definitely a problem. I thought since it was a Jest thing, yarn or nom wouldn't make a difference. But after 16 minutes, the test phase of the CI pipe is still running.
In the CRA docs it says Although we recommend running your tests in watch mode during development, you can disable this behavior by passing in the --watchAll=false flag. In most CI environments, this is handled for you
It links to another section on CI servers which shows that you can set the CI flag. It has info about Travis, Circle CI and your own environment. Based on the last section, the macOS/Linux shows:
CI=true npm test
Will try this.
The above CI=true approach seemed to work for the tests to run once, but there were two failing tests for the second PR.
The output from the test shows that a snapshot test failed due to a date difference.
- Snapshot
+ Received
- value="02/15/2020"
+ value="02/14/2020"
Could this be an issue with the datepicker using the local time which results in a different date? We are using February 15 in our tests, but the datepicker, when using the same input returns a day earlier. It certainly seems like that's the issue.
Running CI=true npm test
locally to see what happens, all the tests appear to pass, but the run fails:
Snapshot Summary
› 1 snapshot obsolete from 1 test suite. To remove it, re-run jest with `-u`.
↳ src/components/dynamicForms/inputs/InputTextField.test.tsx
• validates the input field 1
Test Suites: 5 passed, 5 total
Tests: 19 passed, 19 total
Snapshots: 1 obsolete, 3 passed, 3 total
Time: 35.823s, estimated 105s
Ran all test suites.
npm ERR! Test failed. See above for more details.
Re-running with the -u
flag to update the snapshot as recommended there. But that doesn't help.
Had to comment out the date picker default date and main dynamic forms component snapshot test to avoid the date from breaking the CI pipe. After that, the PRs complete their checks and can be merged. More work needs to be done to get the date picker to use a specific locale. This may as well be a feature so the user can take advantage of it. Raising another issue for this specifically.
One of the goals of this project was to create a production ready app. This indicates a dev ops CI/CD pipeline which is triggered on pull requests from the develop and master branch that then lints, tests, and deploys the app.
This article provides a good run through of what we want. We are using nom while it uses yarn.
Deployments will be to two AWS S3 buckets, one for staging (develop branch) and one for production (master branch).
Regarding using nom instead of yarn, I'm hoping the
--watchAll=false
flag will work the same with npm.