Paul Nothaft
40eb03f0d8
The 3.94.0-beta.0 release PR (#859) failed its backend job on workflowEngine.test.js: bootCrmDb() runs every core migration in beforeAll, and with migrations 163-165 merged the setup crossed the suite's jest.setTimeout(30000) on CI runners — the log shows migration 099 still seeding after the hook timed out. Same pass is green locally and passed on #857's rebase minutes earlier: borderline-slow, not deterministic. - jest.config.js: testTimeout 120000 as the default, so bootCrmDb suites without an explicit pin stop being time bombs as the chain grows - every suite-level jest.setTimeout below 120s raised to 120s — local pins OVERRIDE the config default, so the 30s/60s ones would keep flaking regardless of the global bump No test logic changed anywhere. Co-authored-by: Paul Nothaft <paul@MacStudio-von-Paul.local>
18 lines
559 B
JavaScript
18 lines
559 B
JavaScript
module.exports = {
|
|
testEnvironment: 'node',
|
|
// bootCrmDb() runs EVERY core migration in beforeAll; the chain keeps
|
|
// growing (163-165 pushed several suites past jest's default on CI
|
|
// runners — the 3.94 release PR failed on exactly this). 120s matches
|
|
// the convention the newer suites already pin explicitly.
|
|
testTimeout: 120000,
|
|
coverageDirectory: 'coverage',
|
|
collectCoverageFrom: [
|
|
'src/**/*.js',
|
|
'!src/**/*.test.js'
|
|
],
|
|
testMatch: [
|
|
'**/__tests__/**/*.test.js'
|
|
],
|
|
setupFilesAfterEnv: ['<rootDir>/jest.setup.js']
|
|
};
|