Skip to content
Documentation

Docs / Adapter commands / sbt 2

sbt 2 adapter

Reuse sbt 2 build results through a shared REAPI cache while the tool keeps control of task identities and local execution.

Command
boringcache sbt
Protocol
REAPI gRPC action cache and content-addressable store; cache only
Action
mode: sbt

How the adapter works

Native client configuration

Use sbt 2 and addRemoteCachePlugin in project/plugins.sbt. sbt 1 uses a different remote-cache protocol. Optional global-base selects the global settings directory and must not contain whitespace. Native relative paths use the repo-plan directory and Docker requires an absolute container path. The native adapter preserves other SBT_OPTS and the global base used for plugins. It copies existing global .sbt settings into a private directory, adds cache settings there, and uses a private server directory. Each invocation has its own settings snapshot; setup and cleanup leave the original files unchanged. An existing -Dsbt.global.settings selects which settings to copy.

Shared cache lifecycle

The adapter selects the cache tag, starts a loopback REAPI endpoint, runs the client, and drains cache writes before shutdown. A cache miss runs the task locally.

Read and write policy

Read-only runs do not publish cache entries. Trusted writable runs may publish. Unknown or misplaced adapter options fail before cache startup.

Set up sbt 2

Commit this configuration and run boringcache sbt. Omit command when the Action should prepare caching for several later commands. Use sbt 2 and addRemoteCachePlugin in project/plugins.sbt. sbt 1 uses a different remote-cache protocol. Optional global-base selects the global settings directory and must not contain whitespace. Native relative paths use the repo-plan directory and Docker requires an absolute container path. The native adapter preserves other SBT_OPTS and the global base used for plugins. It copies existing global .sbt settings into a private directory, adds cache settings there, and uses a private server directory. Each invocation has its own settings snapshot; setup and cleanup leave the original files unchanged. An existing -Dsbt.global.settings selects which settings to copy.

workspace = "my-org/my-project"

[adapters.sbt]
tag = "sbt-build"
command = ["sbt", "compile"]

Before the first run

  • Install the project’s sbt 2 version before running the adapter.
  • Review boringcache sbt --dry-run --json before the first build.
  • Remote execution is not provided; use an empty REAPI instance name.

Building inside Docker? Follow the Docker REAPI tool-cache setup to select this tool, its cache tag, and its read/write policy.

Use the same adapter in GitHub Actions

A committed adapter command runs in this Action step. Without one, the Action prepares caching for later tool commands and removes its temporary configuration after stopping the client and cache service.

.github/workflows/ci.yml 
- uses: boringcache/one@696d081c557c070471a175d72aa67d27709a3f31 # v1.40.0
  with:
    trust-policy: auto
    mode: sbt

Approve the repository through Connect CI and grant the job contents: read and id-token: write. The Action uses that Machine connection. Pull requests restore by default; trusted jobs may publish. See the authentication example in the GitHub Actions reference for scoped credentials when OIDC is unavailable.

GitHub Actions reference

Benchmarks

Native client cold and warm cache qualification is separate from an OSS project benchmark. No project speedup is claimed for this managed adapter.

All benchmarks

Tool reference

Check the tool's own reference when you need cache-key rules, build settings, or version-specific behavior.

All adapter commands

Compare every supported command, protocol, and Action mode in one place.

Adapter command index →

Need help or found something unclear? Open an issue or browse the CLI repo.