Local runs

Should I run it locally?

If you're a library author, yes.

If you're maintaining the community build as a whole, go the Jenkins route first and get familiar with that as it's usually more practical. You can decide later whether to supplement Jenkins with local runs.

How do I run it locally?

You might want to set JAVA_HOME first.

Use Java 8. (Unless, of course, you are specifically interested in troubleshooting issues that are specific to JDK 11+.)

You need to install cloc (brew install cloc).

The source and build artifacts that dbuild produces require at least 30GB of disk space.

Several gigabytes of network data are retrieved with git.

Then do:

./run.sh

That's it. It will take hours, so while you wait, make yourself a sandwich. (Even better, make yourself a sandwich-making machine.)

You're also free to specify the nightly Scala you want, e.g.:

version=2.13.2-bin-933bab2 ./run.sh

but you don't have to. If you don't, the version specified in nightly.properties will be used; this is usually a recent-ish nightly build.

Building only certain projects

You can build just a subset if you want:

./run.sh scalatest,scalacheck,specs2,utest

This will build only the listed projects and their dependencies. (In the Jenkins GUI, use the projects setting for this.)

Note that dbuild will still extract dependencies for all projects before building any of them. The first time you run the build for a particular Scala version, it takes at least an hour, so you might want to start that ahead of time and then go make yourself a sandwich or do other work. Or, to save time, see next section.

Extracting only certain projects

Extracting dependencies for all projects can take over an hour. After that, and assuming you didn't e.g. change Scala versions, then the results are cached and it will only take about 4 minutes. But even 4 minutes is annoying when you're actively troubleshooting something

The narrow script lets you save on extraction time by removing unneeded projects temporarily from projs.conf. This can be a huge time-saver, not only on the first run, but also during subsequent runs even when extractions are cached.

Example usage: ./narrow akka. Or, you can specify multiple targets separated by spaces, e.g. ./narrow specs2 scalatest utest.

The script works by reading dependency information from dependencies.txt and then altering projs.conf. (Don't check the projs.conf changes in to version control.)

Can I use a locally built Scala?

Yes, version= works with any Scala version dbuild can resolve.

After publishLocal in scala/scala you'll see e.g.

published ivy to /Users/tisue/.ivy2/local/org.scala-lang/scala-compiler/2.13.2-bin-SNAPSHOT/ivys/ivy.xml

So then you can:

version=2.13.2-bin-SNAPSHOT ./run.sh

This works because resolvers.conf includes local.

The build is painfully slow, what helps?

Work on a subset

See "Extracting only certain projects", above.

Running Artifactory locally

See Local Artifactory for guidance.

Local caches

Note: Caching is enabled by default when running locally. However, if you're using Jenkins or any other CI as a service to run the community build, be sure to verify these items are cached:

1. Cache the Community Build git branch (most services take care of this for you by default):

.git/

2. Scala and dbuild/sbt dependencies (most systems that support Scala also know to do this):

~/.ivy2/cache/
~/.sbt/
~/.m2/

3. Coursier's cache (used as a part of sbt dependency resolution)

See https://get-coursier.io/docs/cache.html#default-location for the official reference, but they should be:

• ~/.cache/coursier/v1 on Linux (and FreeBSD)
• ~/Library/Caches/Coursier/v1 on macOS
• %LOCALAPPDATA%\Coursier\Cache\v1 (e.g. C:\Users\Alex\AppData\Local\Coursier\Cache\v1)

(There's also the older ~/.coursier/cache/v1 path, but that's from versions of Coursier in 2017 or earlier.)

4. Clones, extractions and build cache of dbuild

~/.dbuild/cache-0.9.16/
clones-0.9.16/
target-0.9.16/extraction/