How it works
The buildpack will detect your app as Scala if it has a
project/build.properties file and either a
.scala based build config (for example, a
build.sbt file). It vendors a version of sbt into your slug (if you are not using sbt-native-packager, it also includes your popluated
.ivy/cache in the slug). The
.ivy2 directory will be cached between builds to allow for faster build times.
It is strongly recommended that you use sbt-native-packager with this buildpack instead of sbt-start-script. The latter is deprecated, and will result in exessively large slug sizes.
For more information about using Scala and buildpacks on Heroku, see these articles:
- Heroku's Scala Support
- Play Documentation: Deploying to Heroku
- Customizing the JDK
- Running a Remote sbt Console for a Scala or Play Application
- Reducing the Slug Size of Play 2.x Applications
There are a number of example applications that demonstrate various ways of configuring a project for use on Heroku. Here are a few:
In some cases, builds need to clean artifacts before compiling. If a clean build is necessary, configure builds to perform clean by setting
$ heroku config:set SBT_CLEAN=true Setting config vars and restarting example-app... done, v17 SBT_CLEAN: true
All subsequent deploys will use the clean task. To remove the clean task, unset
$ heroku config:unset SBT_CLEAN Unsetting SBT_CLEAN and restarting example-app... done, v18
To make changes to this buildpack, fork it on Github. Push up changes to your fork, then create a new Heroku app to test it, or configure an existing app to use your buildpack:
# Create a new Heroku app that uses your buildpack heroku create --buildpack <your-github-url> # Configure an existing Heroku app to use your buildpack heroku config:set BUILDPACK_URL=<your-github-url> # You can also use a git branch! heroku config:set BUILDPACK_URL=<your-github-url>#your-branch
Licensed under the MIT License. See LICENSE file.