Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.grounds.gg/llms.txt

Use this file to discover all available pages before exploring further.

grounds push is the command you’ll run dozens of times a day. It’s a thin wrapper over the Gradle plugin: the CLI invokes ./gradlew groundsPush with the right arguments and inherits its stdout.

Synopsis

grounds push [--target=dev|staging] [--project <id>]
grounds push retry <pushId>
grounds push list [--target T] [--status S] [--limit N]

push

grounds push --target=dev       # default
grounds push --target=staging
Runs ./gradlew groundsPush --target=<t> in the current directory. The Gradle plugin handles:
  • Resolving the JAR (auto-detects shadowJar or jar).
  • Reading and validating grounds.yaml.
  • Uploading JAR + manifest to forge.
  • Streaming build + deploy logs back to your terminal.
  • Exiting with a non-zero code on any terminal failure.
The CLI exits with the same code Gradle exits with.

push retry

grounds push retry <pushId>
Re-runs the pipeline for a previously failed push. Forge re-uses the server-stored JAR and manifest, so this doesn’t re-upload — it goes straight from pending to building. Use it when:
  • A build failed because of a transient infra issue (image pull, registry hiccup).
  • A deploy failed and you want to try again without rebuilding.
The retry creates a new push row with its own ID; the original is preserved for history.

push list

grounds push list                          # last 20 in current project
grounds push list --target=staging
grounds push list --status=ready
grounds push list --limit=50
grounds push list --output=json | jq .
FlagPurpose
--targetFilter by target: dev, staging, production.
--statusFilter by state: pending, building, build_failed, build_succeeded, deploying, deploy_failed, ready.
--limitMax rows to fetch (default 20, server cap 200).
--outputtable (default), json, or yaml.

Common flags

These are all global flags and apply to every subcommand:
FlagEnvPurpose
--project <id>GROUNDS_PROJECTPin the project for this call
--api-url <url>GROUNDS_API_URLOverride the forge endpoint
--config <dir>GROUNDS_CONFIG_DIROverride config dir
--output <fmt>table / json / yaml
--verbose / -vDebug logs to stderr
--no-colorNO_COLOR=1Disable ANSI colors

Reading the output

A successful push looks like:
→ uploading my-cool-plugin-0.1.0.jar (4.2 MB)
✔ uploaded — pushId=018f9c12-…
[build] step 1/5 …
[build] step 5/5 done
✔ build_succeeded — image registry.platform.grnds.io/my-cool-plugin@sha256:…
[deploy] reconciling deployment my-cool-plugin in user-hendrik
[deploy] pod scheduled
[deploy] pod ready
✔ ready — connect at my-cool-plugin-hendrik.mc.grnds.io
If the pod ends up CrashLoopBackOff, you’ll see deploy logs streamed before the CLI gives up and prints deploy_failed. Tail the live deployment logs separately at any time:
grounds logs deployment my-cool-plugin

Exit codes

CodeMeaning
0ready reached
1Generic failure (validation, network, config)
2build_failed
3deploy_failed
130Cancelled by user (Ctrl-C)
Anything non-zero is safe to fail a CI step on.