-
-
Notifications
You must be signed in to change notification settings - Fork 93
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Only compile if no compilation is currently already in progress (#139)
When rails tests are run in parallel, multiple `webpack` compilations are kicked off at the same time. This is _really_ resource intensive and slow.
- Loading branch information
Showing
2 changed files
with
42 additions
and
5 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
243d3f2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This commit is causing us issues with our CI server -- because of some ancient environmental choices, we have to precompile assets on our Jenkins host before deploying the application to VMs for testing. We frequently have multiple compilations going in parallel, but each build needs its own version of the assets for its particular branch to deploy. Yes, it's resource-intensive, but it's what we need with our setup. Having the lockfile in the server's tmp directory, always with the same name, means only one of those builds will succeed and the rest fail (which I get was the point of the commit). They don't wait for compilation, they just....don't compile and the builds move on and deploy without the compiled assets, and tests fail.
The lockfile is also not being automatically removed when the process is completed, at least for us. It certainly seems like it should be. It's not impossible that's on us somehow, but I'm still looking into that.
I've monkey-patched this file in our repo for now to elide the
wait_for_compilation_to_complete
method so that it won't hold up the builds, and things seem to be running smoothly. But it would be great not to have to maintain that patch forever. I expect we're not the only team to run into a problem like this, so I think this solution could use a bit of tweaking, even if it just means making it configurable whether to use the lock or not. Moving to Shakapacker has been a huge win for us, but this one thing has caused me several days of headaches running it down.