skip to content

Why does the conditional signing predicate include `!version.endsWith('-SNAPSHOT')`, and what would go wrong if you omitted it?

level: middleimportance: should knowfreq 38%

answer

  1. release = immutable, signed; SNAPSHOT = mutable, unsigned
  2. Central requires signatures; snapshot repo does not
  3. drop the check => every snapshot publish needs the key
  4. couples high-freq flow to the sensitive release key
  5. version.toString().endsWith('-SNAPSHOT')

basics

~20 s

SNAPSHOTs are mutable pre-release builds that repositories don't require to be signed. The -SNAPSHOT check skips signing for them so frequent dev publishes don't need a key, while only immutable release versions are forced to sign.

solid answer

~40 s

Maven versioning distinguishes **release** versions (immutable, e.g. `1.4.0`) from **SNAPSHOT** versions (mutable, e.g. `1.4.0-SNAPSHOT`). Snapshot repositories (like Sonatype's snapshot repo) accept unsigned uploads and are republished constantly during development, so requiring a PGP signature on every snapshot publish would be pointless friction and would break CI machines without a key. The release repository (Maven Central) **does** require signatures. So `!version.endsWith("-SNAPSHOT")` ensures `isRequired` is true only for releases. Omit it and every `publish` — including the dozens of snapshot publishes a day — would hard-fail unless a signing key is present, defeating the purpose of conditional signing and likely breaking your snapshot CI pipeline. The check is just string-suffix matching on the project `version`.

code

kotlin · 4 lines
kotlin
val isRelease = !version.toString().endsWith("-SNAPSHOT")
signing {
    isRequired = gradle.taskGraph.hasTask("publish") && isRelease
}

go deeper

for a junior

Know SNAPSHOT = dev/pre-release and shouldn't force signing; releases must be signed.

for a middle

Explain immutability of releases, Central's signature requirement, and why omitting the check breaks snapshot CI.

for a senior

Discuss coupling high-frequency snapshot flow to the sensitive release key and robust version detection.

for a principal

Frame as separation of concerns between snapshot and release pipelines and secret-exposure minimization.

## Release vs. SNAPSHOT in a sentence In Maven-style versioning: - A **release** version (`1.4.0`) is **immutable** — once published it can never change. Central enforces this and requires the artifact to be **PGP-signed**. - A **SNAPSHOT** version (`1.4.0-SNAPSHOT`) is **mutable** — every publish overwrites the prior snapshot. Snapshot repositories explicitly allow this and do **not** require signatures. ## Why the predicate has two parts ```kotlin isRequired = gradle.taskGraph.hasTask("publish") && !version.toString().endsWith("-SNAPSHOT") ``` - `hasTask("publish")` → only when actually publishing (not on `build`). - `!...endsWith("-SNAPSHOT")` → only for releases. Both must be true to *require* signing. The result: plain builds, and snapshot publishes, never force a signature; release publishes do. ## What breaks if you drop the SNAPSHOT check With only `isRequired = gradle.taskGraph.hasTask("publish")`: - Every snapshot publish (often automated, many times a day) now demands a valid signing key. - CI agents that publish snapshots but don't hold the release GPG key fail hard. - Developers doing `publishToMavenLocal` of a snapshot get spurious failures. You'd have effectively coupled high-frequency, low-stakes snapshot flow to your most sensitive secret (the release key), which is both annoying and a security-surface problem. ## Practical robustness `version` is an `Any` (often a `String`), so call `.toString()` before `endsWith`. Some teams use `version.toString().endsWith("SNAPSHOT")` to also catch unusual suffixes, or check `(version as String).contains("SNAPSHOT")`. The intent is the same: detect a non-final version.

  • Does Maven Central accept SNAPSHOT releases at all?
    No. Central hosts only release versions and rejects SNAPSHOTs; snapshots go to a separate snapshot repository that permits mutable, unsigned uploads.
  • Why cast/convert version with `.toString()`?
    The project `version` is typed as `Any`, so you call `.toString()` before string operations like `endsWith` to compile cleanly and handle non-String version objects.

saying these in an interview costs you the question

  • Saying snapshots must also be signed by repositories — they generally are not required to be.
  • Treating SNAPSHOT versions as immutable; they are explicitly mutable.

context

resolving links…