Faster CI #1388
Faster CI #1388
Conversation
redallen
force-pushed
the
feature/circleci
branch
from
ca6637f
to
72f7738
Compare
|
Deploy preview for patternfly-react-gone ready! Built with commit a85ba13 https://deploy-preview-1388--patternfly-react-gone.netlify.com |
|
Well, I had to rewrite |
|
PatternFly-React preview: https://1388-pr-patternfly-react-patternfly.surge.sh |
|
This should fix the double preview commenting. As an aside, I have no idea what bot made the netlify upload! |
| git: | ||
| depth: 1 | ||
| depth: 10 |
There was a problem hiding this comment.
So Travis won't trip over itself checking out an old commit after a new build has fired
| @@ -1,8 +1,5 @@ | |||
| { | |||
| "lerna": "3.10.5", | |||
| "nohoist": [ | |||
There was a problem hiding this comment.
Hoisting babel doesn't break any task that I'm aware of
| "test:current": "jest --watch", | ||
| "test:integration": "lerna run integration:setup && lerna run build:demo && lerna run integration:test", | ||
| "test:watch": "jest --watchAll", | ||
| "travis-deploy-once": "travis-deploy-once" |
There was a problem hiding this comment.
No longer need this thanks to Travis build stages
| ] | ||
| }, | ||
| "resolutions": { | ||
| "cssom": "0.3.4" | ||
| "cssom": "0.3.4", | ||
| "terser": "3.14.1" |
There was a problem hiding this comment.
pr-build occasionally fails on CircleCI for no known reason. This might fix it? gatsbyjs/gatsby#11508
| @@ -4,40 +4,6 @@ | |||
| "config": { | |||
| "access": "private" | |||
| }, | |||
| "devDependencies": { | |||
There was a problem hiding this comment.
These are ignored by yarn since the package has no version, and there's nothing we can do about it :(
| @@ -4,33 +4,12 @@ | |||
| "config": { | |||
| "access": "private" | |||
| }, | |||
| "devDependencies": { | |||
There was a problem hiding this comment.
These are ignored by yarn since the package has no version, and there's nothing we can do about it :(
| @@ -32,7 +32,7 @@ | |||
| "@patternfly/react-styles": "^2.3.2", | |||
| "@patternfly/react-tokens": "^2.0.1", | |||
| "@tippy.js/react": "^1.1.1", | |||
| "emotion": "^10.0.6", | |||
| "emotion": "^9.2.9", | |||
There was a problem hiding this comment.
Consistent emotion version
| "build:tsd:copy": "node ./scripts/copyTS.js", | ||
| "lint": "tslint --project tsconfig.json", | ||
| "postbuild": "yarn build:typecheck && node ./build/copyStyles.js" | ||
| "build:ts": "node ./scripts/copyTS.js", |
Pull Request Test Coverage Report for Build 4562
💛 - Coveralls |
| @@ -37,8 +37,8 @@ | |||
| "gatsby" | |||
| ], | |||
| "scripts": { | |||
| "docbuild": "node build/copyDocs.js && node --max_old_space_size=4096 ./node_modules/.bin/gatsby build", | |||
| "pr-build": "node build/copyDocs.js && node --max_old_space_size=4096 ./node_modules/.bin/gatsby build --prefix-paths", | |||
There was a problem hiding this comment.
these were added to increase the available memory for the node process as gatsby is sometimes hitting it and then erroring out. Is this not needed anymore?
There was a problem hiding this comment.
The module resolution is the bigger problem. If Gatsby gets hoisted, it won't be in that path.
There was a problem hiding this comment.
Can we adjust the path to go to the relative root?
There was a problem hiding this comment.
We could, but could you convince me of when Gatsby could run out of memory? I haven't experienced it on Travis or CircleCI, which have 7.5GB and 4GB of RAM respectively.
There was a problem hiding this comment.
Gatsby definitely uses a lot of ram, but if it runs out it would typically error out like this:
success createPages — 16.948 s
success createPagesStatefully — 0.120 s
success onPreExtractQueries — 0.014 s
success update schema — 6.081 s
success extract queries from components — 0.265 s
⠁
<--- Last few GCs --->
[11566:0x37ab5d0] 73868 ms: Mark-sweep 1416.3 (1495.9) -> 1416.3 (1479.9) MB, 915.0 / 0.0 ms (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 915 ms) last resort
[11566:0x37ab5d0] 74780 ms: Mark-sweep 1416.3 (1479.9) -> 1416.3 (1479.9) MB, 912.6 / 0.0 ms last resort
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0x196898628799 <JSObject>
0: builtin exit frame: captureStackTrace(aka captureStackTrace)(this=0x393b29c02311 <undefined>,0x2f691ed37cd1 <JSFunction CapturedTrace (sfi = 0x25975f15c491)>,0x328575c09329 <CapturedTrace map = 0x38644cc40001>)
1: _then [/mnt/c/Users/brand/code/admitbrain/node_modules/bluebird/js/release/promise.js:~219] [pc=0x2c92629e6e1f](this=0x3470fb292b09 <Promise map = 0x38644cc400b1>,didFulfil...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
I have not seen the terser error before though, not too sure where that's coming from
There was a problem hiding this comment.
I found an environment variable env NODE_OPTIONS=--max_old_space_size=4096, that way a relative path isn't necessary.
What: Revamp Travis to use parallel tasks and add CircleCI to deploy lengthy PR previews instead of Travis for faster PR approvals.
Travis Builds
⏩: In parallel
🏁: If release (commit to master on patternfly/patternfly-react)
🏴: If pull request
Use Travis to mainly handle PR testing. It is still used for deploys (for now). Use CircleCI to deploy PR Docs.
Time comparison
Continuing issues:
yarn installandyarn buildstill takes 6-9 minutes on Travis. Need to conditionallyyarn installbased off the checksum ofyarn.lock(like with CircleCI) to save 3-4 minutes here. Need to look into cleaning dependencies to save on install time.Additional issues: