-
-
Notifications
You must be signed in to change notification settings - Fork 633
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Asset precompilation in the test environment uses build_production_command #1202
Comments
As alluded to in that file, the right solution might be to better integrate with webpacker: react_on_rails/lib/tasks/assets.rake Lines 58 to 61 in 0e7c86c
|
@shepmaster The reason why the precompile task uses the production build is that I set this up for precompiling during production deploys. I was not aware that anybody would want to precompile for any other purpose. Why not just build the test bundles as part of your CI script? |
We have multiple parallel CI jobs. Running the first test in each of these with on-demand compilation causes the first test to fail due to long compilation times. We precompile the test assets once to:
Perhaps I'm misunderstanding you, but that's sort of what this issue is about. We do build them now, but via Perhaps you can suggest another way I can state the issue; I'm not sure that I'm communicating clearly. |
@shepmaster do you need precompilation for anything other than the JS assets? If not, I'd recommend that you run the webpack build separately during your CI setup after the packages are installed. You are correct in that you don't want to build the assets for every parallel CI job. On circleci, we cache the results. |
If I run
Then the task
react_on_rails:assets:webpack
is run. However, this unconditionally usesbuild_production_command
:react_on_rails/lib/tasks/assets.rake
Line 65 in 0e7c86c
My ideal case would be for
rake assets:precompile
to understand the environment it is run in.Our current workaround is to also run the webpacker task, which handles the environment correctly:
This is unfortunate as the double compilation slows down our CI builds.
The text was updated successfully, but these errors were encountered: