Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save bostontrader/0739f5794eab30339c7a105d4da15e5e to your computer and use it in GitHub Desktop.
Save bostontrader/0739f5794eab30339c7a105d4da15e5e to your computer and use it in GitHub Desktop.
webpack-elm-loader appears to hang on Travis CI

TL;DR: If this is happening to you, just add the line sudo:required to travis.yml.

After a suitable amount of pulling of hair (my own), gnashing of teeth, and general fretting, I have found a solution to a rather nettlesome issue. I have some elm code in a project that uses webpack and Travis CI. It all works fine locally, but when I tried to build it on Travis, the webpack command apparently hung without any warnings or other clues.

At first I guessed that the problem might be the fact that by default, at the time of this problem, Travis was setting me up with Ubuntu 14.04. This being a rather long-in-tooth edition by now, perhaps that's a problem. My research into how-to-specify a more recent version of Ubuntu was discouraging because apparently that was the latest edition available. I was welcome to redesign the entire CI process to use docker instead, but that sounded like work, so I contemplated further.

I next figured that perhaps the problem was between webpack and Travis. I found that if I commented out various rules in webpack.config.js, webpack appeared to work just fine, except it would barf when it encountered files that required the missing rules and loaders. In playing this game I quickly narrowed the problem to webpack-elm-loader.

In researching webpack-elm-loader I began to find some real clues. Apparently there's some issue with Travis CI reporting the wrong number of CPUs available and this confuses all things elmy. There exists a good thread about this in case you're interested. This thread suggests that webpack-elm-loader does not really "hang." Instead, it's takin' its time to finish. After 10 minutes of no output, Travis pulls the plug and another one bites the dust. I was unable to override this 10 minute limit, and even if I could, that would have been just a very crude hack.

The thread also suggests a few variations of a rather tedious contortion that involves downloading and building some obscure utility to correct the misreporting of the CPU population and to persuade elm to use said utility. Sounding again like work, I soldiered on...

Finally...

lost somewhere beyond DarkNet I found reference to "just add sudo:required to travis.yml". Ding! The board turns green. I raise my chalice to my divinely inspired benefactor. Although I cannot directly reference its contribution because I don't have the link, I can write this humble gist and hopefully get it pushed more firmly in the face of the people who next wander lost into the same labyrinth as I.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment