If you want to learn the REAL reason your Elm builds are taking so long on Travis CI, be sure to read through to the end of this post. The answer will shock you!

To understand where the problem is, it helps to look at everything that happens during a build. Installing dependencies and compiling an Elm application includes several steps.

• First, the Elm package manager determines which versions of which packages are required based on the app's elm-package.json.
• If the package manager can resolve all the dependencies, it saves the package name and version of every package to be installed in elm-stuff/exact-dependencies.json.
• It then pulls down all the packages in to elm-stuff/packages.
• Then, the .elm files from both your project and the installed packages are compiled to .elmi and .elmo files in elm-stuff/build-artifacts.
• Finally, all the .elmo files are compiled in to one big .js file.

The step of compiling the Elm code to the intermediate .elmi and .elmo files is particularly slow on Travis, because each build must recompile every file from scratch.

If you're thinking, "But there has to be a better way!"; there is! You really only need to recompile the files that have changed since the last build! So if you're ready to quit with those long builds, you can cache the build artifacts by adding the following lines to your .travis.yml (assuming that your script is compiling in the tests directory, otherwise replace tests with wherever your project is building relative to the project root):

cache:
		directories:
				- tests/elm-stuff/build-artifacts

With this cache in place, only modules that have changed (and the Main module) need to be recompiled. Testing this out on a minimal app that was taking almost seven minutes to build, caching the build artifacts took the build down to 40 seconds. If you want, you can cache the whole elm-stuff directory and shave off a few more seconds. However, that might have other effects, like not resolving to the newest versions of packages unless you update the elm-package.json or manually invalidate the cache.

Note that you won't see results on the first build, because it still needs to create the cache. Once this change has made its way to master though, you should see your build times improve dramatically.

Now you know the secret that Big CI has been hiding from you to keep your builds slow and keep you waiting.