Guardrails / scala

Scala dependencies are pinned

scala/dependencies-pinned@v1

Every library dependency found in the build names a literal revision. build.sbt is Scala code read by pattern, so a dependency built by a function, added inside a condition or held in a variable isn't detected, and the list may be incomplete.

Id	scala/dependencies-pinned
Version	v1
Category	scala
Default severity	warning
Interpreter	python3
Timeout	30 seconds
Violations tolerated	0
Collects	scala

Collectors

This guardrail doesn't gather anything itself. It relies on the collectors below, which the CLI runs once per build before any check, and reads what they found from GUARDRAIL_FACTS. If a collector collects nothing, this guardrail is skipped, not failed.

Collector	Gathers	Inputs it is given
scala	The sbt build in the project directory: the Scala and sbt versions it pins, every subproject the reader saw, the library dependencies each build file names with their configurations, and the plugins the build itself runs. build.sbt is Scala rather than a declaration, so what it declares indirectly is not seen and scanned says so.	projectDir

The inputs above are this guardrail's own inputs, passed straight through to the collector. Setting one in buildnote.json changes what is collected, and two guardrails configured the same way share a single collection.

Configuration

{
  "guardrails": {
      "failOn": "error",
      "checks": [
          {
              "use": "scala/dependencies-pinned@v1",
              "severity": "warning",
              "with": {
                  "projectDir": "."
              },
              "exemptions": []
          }
      ]
  }
}

Inputs

Input	Description	Default	Environment variable
projectDir	Directory holding the project, relative to the directory the CLI runs in.	.	GUARDRAIL_INPUT_PROJECTDIR

How to fix

Write the revision as a literal in the entry that declares the dependency:

libraryDependencies += "org.typelevel" %% "cats-effect" % "3.5.4"

sbt expects a literal revision, not a range. An entry that isn't one is either a moving revision such as latest.integration, which resolves to whatever the repository serves that day, or a reference this guardrail can't follow. build.sbt is read by pattern here, not evaluated as a build, so a revision held in a val or produced by a function also shows as unresolved. Writing the revision in the entry itself puts the version in the diff that changes it.

More in scala

• scala/no-snapshot-dependencies. No library dependency found in the build is a -SNAPSHOT. build.sbt is Scala code read by pattern, so dependencies it declares indirectly aren't detected, and the list may be incomplete.
• scala/sbt-version-pinned. project/build.properties pins the sbt version the build runs with, instead of leaving it to whichever launcher the machine has.
• scala/version-declared. The build declares the Scala version it compiles against, and that version is no older than the configured floor.

All 4 scala guardrails