Pre-compile all needed assets in CI environment #12552
Conversation
mkllnk
added
the
technical changes only
We use Webpacker *and* Sprockets to compile assets. I hadn't realised before that we were still compiling lots of JS with Sprockets. So even after we pre-compiled assets with Webpacker, we still needed to compile more assets on the first page visit in test environment. That made some time-critical specs, like caching specs, fail. This approach pre-compiles all assets but only in CI. Running the compilation task adds 6.5 seconds even if there's nothing to compile while the previous Webpacker call returned instantly. So I decided to run the compilation only on CI and activated on-demand compilation to the test environment. Time-critical specs will still be flaky without pre-compilation locally but I figured that a fair trade-off for faster specs in general. During most development, we don't need all assets to be compiled and it's faster to just compile what's needed. And running a time-critical spec twice solves the flakiness.
I'm not sure why, but the pre-compiling of assets triggered Rails to render `style="..."` instead of `style='...'` in this case. But when assets are compiled on-demand, we get the single quotes. So I changed the spec to be agnostic of this detail. We actually just want to know about the link and its href.
mkllnk
changed the title
|
Sorry I didn't get to have a good look at this yet. I don't like the idea of adding 6.5sec to most CI runs, but I'm not sure there's any better solutions. Maybe if we can isolate those specs that require sprockets we can run it only where needed. Will have a look next week. |
|
Given that this adds time to compile all assets, which might not be used, I had a go at Cache public assets in CI. |
|
Oh, I had not realised that this is doubling CI run time, from 6 minutes to 12 minutes. That's not great, of course. The easiest quick fix in this case would be to put a |
Hmm that's weird, but certainly not good! Ideally, I'd like us to be able to cache the necessary parts to speed up the asset compilation, AND pre-compile as per this PR, because that replicates a prod instance. But it doesn't seem practical, so |
What? Why?
We use Webpacker and Sprockets to compile assets. I hadn't realised
before that we were still compiling lots of JS with Sprockets. So even
after we pre-compiled assets with Webpacker, we still needed to compile
more assets on the first page visit in test environment. That made some
time-critical specs, like caching specs, fail.
This approach pre-compiles all assets but only in CI. Running the
compilation task adds 6.5 seconds even if there's nothing to compile
while the previous Webpacker call returned instantly. So I decided to
run the compilation only on CI and activated on-demand compilation to
the test environment.
Time-critical specs will still be flaky without pre-compilation locally
but I figured that a fair trade-off for faster specs in general. During
most development, we don't need all assets to be compiled and it's
faster to just compile what's needed. And running a time-critical spec
twice solves the flakiness.
Do you agree with this approach? Do you have a better idea?
What should we test?
Release notes
Changelog Category (reviewers may add a label for the release notes):
The title of the pull request will be included in the release notes.
Dependencies
Documentation updates