skip to content

What does the ORG_GRADLE_PROJECT_<name> environment variable do, and when would you use it instead of -P?

level: middleimportance: must knowfreq 60%

answer

  1. ORG_GRADLE_PROJECT_x sets project property x
  2. env-var equivalent of -Px
  3. CI delivers config as env vars
  4. keeps secrets off the command line
  5. read via providers.gradleProperty

basics

~10 s

ORG_GRADLE_PROJECT_name=value sets a Gradle project property named name via an environment variable — equivalent to -Pname=value, but without putting it on the command line. Handy in CI where you inject env vars.

solid answer

~40 s

`ORG_GRADLE_PROJECT_<name>=<value>` is the environment-variable form of a project property: Gradle strips the `ORG_GRADLE_PROJECT_` prefix and registers a project property called `<name>`, exactly as if you'd passed `-P<name>=<value>`. The value is then readable through `findProperty("<name>")` or `providers.gradleProperty("<name>")`. You reach for it in **CI/CD** because secrets and config are typically delivered as environment variables, not command-line args. Putting a token on the command line (`-Ptoken=...`) exposes it in process listings and build logs; injecting it as `ORG_GRADLE_PROJECT_token` keeps it in the environment and out of the visible command. There is a parallel `systemProp.` convention (in gradle.properties) and `-D` for system properties, but `ORG_GRADLE_PROJECT_` specifically maps to the **project-property** namespace.

code

bash · 3 lines
bash
export ORG_GRADLE_PROJECT_appVersion=3.1.0
export ORG_GRADLE_PROJECT_publishToken=$CI_PUBLISH_TOKEN
./gradlew publish   # appVersion & publishToken are project properties now

go deeper

for a junior

Recall that ORG_GRADLE_PROJECT_name is the env-var way to set a project property, like -Pname.

for a middle

Explain the prefix-stripping mechanism and that it maps to the project-property namespace, plus the CI use case.

for a senior

Contrast with -D/systemProp. system properties and articulate the secret-hygiene reason to prefer env vars over command-line args.

for a principal

Define a team convention: inject all build inputs and secrets via ORG_GRADLE_PROJECT_ env vars in CI, ban secret-bearing -P args, and document required variables.

## The convention Gradle lets you set a project property through an environment variable using a fixed prefix: ``` ORG_GRADLE_PROJECT_<propName>=<value> ``` Gradle scans the environment, finds any variable starting with `ORG_GRADLE_PROJECT_`, removes the prefix, and registers the remainder as a **project property**. So: ```bash export ORG_GRADLE_PROJECT_appVersion=3.1.0 ./gradlew build # behaves like -PappVersion=3.1.0 ``` Inside the build it is read identically to a `-P` property: ```kotlin val v = providers.gradleProperty("appVersion").getOrElse("0.0.1") ``` ## Why this exists — CI ergonomics and secret hygiene CI systems (GitHub Actions, GitLab CI, Jenkins) deliver configuration and secrets as **environment variables**. The `ORG_GRADLE_PROJECT_` convention lets those flow straight into Gradle project properties with zero glue code. Crucially, command-line arguments are visible in `ps` output and often echoed into logs, so a `-PsigningKey=...` can leak a secret. An env var injected as `ORG_GRADLE_PROJECT_signingKey` is not part of the visible command line, which is the safer channel for sensitive values. ## Namespace mapping (the part people confuse) - `ORG_GRADLE_PROJECT_x` → **project property** `x` (same table as `-Px`) - `systemProp.x=...` in gradle.properties → **system property** `x` (same table as `-Dx`) - A plain env var (e.g. `MY_TOKEN`) is neither; you read it with `System.getenv("MY_TOKEN")` or `providers.environmentVariable("MY_TOKEN")`. So there are two prefix conventions: `ORG_GRADLE_PROJECT_` targets the project-property namespace, while `systemProp.` (an env var `ORG_GRADLE_PROJECT_systemProp...` is NOT how you set system props from env) targets system properties via gradle.properties. Keeping these straight is the whole point of the topic. ## Practical CI snippet ```yaml env: ORG_GRADLE_PROJECT_appVersion: ${{ github.ref_name }} ORG_GRADLE_PROJECT_publishToken: ${{ secrets.PUBLISH_TOKEN }} ``` Both become project properties the build reads with the providers API — no `-P` on the command line, secret stays out of the visible command.

  • Why prefer ORG_GRADLE_PROJECT_token over -Ptoken=... in CI?
    Command-line args appear in process listings and can be echoed into logs, leaking the secret. The env-var form keeps the value out of the visible command line.
  • Is ORG_GRADLE_PROJECT_x a system property or a project property?
    A project property. It maps to the same namespace as -Px and is read via findProperty / providers.gradleProperty, not System.getProperty.
  • How would you set a JVM system property from the environment instead?
    Use -Dx on the command line, or systemProp.x in gradle.properties. ORG_GRADLE_PROJECT_ only feeds project properties, not system properties.

saying these in an interview costs you the question

  • Thinking ORG_GRADLE_PROJECT_x sets a system property readable via System.getProperty.
  • Claiming a plain env var like MY_TOKEN automatically becomes a Gradle project property.
  • Putting secrets on the command line via -P in CI.

context

resolving links…