CI inconsistency/failure with latest stripes-core
Description
CSP Request Details
CSP Rejection Details
Potential Workaround
relates to
Checklist
hideTestRail: Results
Activity
Jeffrey Cherewaty February 6, 2018 at 5:35 PM
Matt Jones February 2, 2018 at 7:25 PM
Note: Jira formatting appears to be messing with the names inline. "webpack_public_path" should be surrounded with two underscores on each end.
Matt Jones February 2, 2018 at 7:22 PM
I've confirmed that _karma_webpack_ is the publicPath assigned to the webpack config by karma-webpack itself.
Does it help that the Webpack public path can be obtained dynamically? Webpack will replace instances of __webpack_public_path__ in the files it parses with the value of public path it is using.
For example, I can drop __webpack_public_path__ into mirage/config.js:
And see it in the output:
Matt Jones February 2, 2018 at 3:09 PM
Thanks for the clarification. It didn't occur to me that yarn.lock would lock to a revision when a just a branch was specified. Would it make sense then to have one CI job running without a lock file? It would seem a quicker feedback loop would be desirable.
The _karma_webpack_ prefix looks suspiciously like Karma's assigned its own public path to the build. The translations are emitted to the output directory, so its necessary to make the fetch request in the browser using whatever public path happens to be in place. I will diagnose it a bit further.
I would think this would come into play requesting other build resources in the output folder, like fonts or images, etc. Are there (or will we need) equivalent pass-throughs for those as well?
Jeffrey Cherewaty February 2, 2018 at 1:51 PM
I won't get to look at this any more today, but a couple things:
Travis didn't update
stripes-cliorstripes-corebecause of theyarn.lock. Even thoughpackage.jsonis set to#master, theyarn.lockstays on a specific commit until explicitly updated.
This might be a dumb question, but why is the translations endpoint prefixed with
_karma_webpack_in test mode? (That prefix isn't there in dev mode.) Can that go away? That will make for a simpler mirage passthrough.
Locally I am not able to run the ui-eholdings tests due to a failure to fetch the translation bundle. With STCOR-49, Stripes now generates a separate translation bundle, rather than rely on them being included in the main bundle. Mirage has no matching routes and reports the following:
Is it possible to define a pass-through for the
/translationsdirectory? These files are emitted to the webpack output directory during a build.Second, related problem appears to be a caching issue in the CI. Although ui-eholdings is pointing to `folio-org/stripes-cli#master`, Travis is reporting version 0.12.0 of the CLI which is not the latest in master.
Given this, it is plausible that while we're pointing to `folio-org/stripes-core#master`, ui-eholdings is not testing with the latest stripes-core either. This would explain why CI didn't catch the failure yesterday.