fix: Exit status code for fatal Webpack exceptions #1754
Conversation
🦋 Changeset detectedLatest commit: 42b1458 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| showStats(stats, true); | ||
|
|
||
| if (err || (stats && stats.hasErrors())) { | ||
| rej(`${red('\n\nBuild failed! \n\n')} ${err || ''}`); | ||
| if (err) { | ||
| error(err, 1); | ||
| } | ||
|
|
||
| showStats(stats, true); | ||
|
|
There was a problem hiding this comment.
showStats(), in production builds, will also immediately exit upon coming across any errors; as such, there's no reason to ever reject this promise as we've already exited.
| @@ -16,6 +16,7 @@ jobs: | |||
| test: | |||
| name: Test | |||
| runs-on: ubuntu-latest | |||
| timeout-minutes: 10 | |||
There was a problem hiding this comment.
Unrelated, but for some (godforsaken) reason, puppeteer randomly never exits on the CI. I've seen no pattern for this, just that it occurs.
GitHub's default is 360 minutes, or 6 hours, which we definitely don't need. I just caught a run still going after an hour and had to manually kill it. 10 minutes should be plenty of time.
rschristian
force-pushed
the
fix/status-code
branch
from
09ad115
to
42b1458
Compare
| "puppeteer": "^9.1.1", | ||
| "puppeteer": "^13.7.0", |
There was a problem hiding this comment.
This shouldn't be necessary, but our version of Puppeteer has turned super flakey recently. Updating seems to make it somewhat less so.
What kind of change does this PR introduce?
bugfix
Did you add tests for your changes?
No
Summary
Closes #1744
We don't correctly handle fatal Webpack exceptions at the moment; the
errin the callback forcompiler.run()relates to fatal Webpack exceptions, like configuration errors. When one is hit, we only reject the promise, which actually allows the build to "complete" with a status code of0. We instead want to exit immediately with a status code1(as that matches what we do for compilation errors).Does this PR introduce a breaking change?
No