docs(variables, database): working ${VAR} references + ZBPACK env vars#57
docs(variables, database): working ${VAR} references + ZBPACK env vars#57marvin-69-jpg wants to merge 1 commit into
Conversation
…CK env vars
Two related corrections:
1. \${VAR} variable references via 'variable update -k' DO work when
single-quoted (verified 2026-04 against CLI 0.15.0). The skill
previously routed users to the dashboard for any cross-service
reference, citing zeabur/cli#201 — that bug appears fixed for the
common case. Soften the warning, give a working multi-key example,
note that exotic values (commas, multiple = signs) may still
trigger Cobra parser issues so verifying with 'variable list' is
prudent.
2. Add a 'zbpack build-time configuration via env vars' section to
zeabur-variables documenting that zbpack reads env vars (via
ZBPACK_<SCREAMING_SNAKE_CASE> of the underlying config key) at
build time. ZBPACK_DOCKERFILE_PATH is the most useful one for
monorepo deploys with multiple Dockerfiles, replacing the need to
swap a root zbpack.json between deploys.
3. zeabur-database: replace the now-stale 'CLI has known bug with \${}'
caveat with the corrected version, and add a tip about constructing
a custom URL scheme prefix (e.g. postgresql+psycopg:// for
SQLAlchemy with psycopg3) by interpolating parts rather than reusing
the pre-built \${POSTGRES_CONNECTION_STRING}.
Same direction as PR zeabur#50 which corrected the parallel
'variable update clears vars' caveat in zeabur-update-service.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 59 minutes and 12 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Two related corrections to bring the skills in line with the actual CLI behavior in version 0.15.0 (observed 2026-04):
1.
${VAR}references viavariable update -kDO work (when single-quoted)The current
zeabur-variablesandzeabur-databaseskills route users to the dashboard for any cross-service variable reference, citing zeabur/cli#201 and labeling the CLI as broken for\${}values. In testing, single-quoted references viavariable update -kare stored correctly and resolve at injection time:```bash
npx zeabur@latest variable update --id \
-k 'DATABASE_URL=postgresql+psycopg://${POSTGRES_USERNAME}:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DATABASE}' \
-k 'REDIS_URL=${REDIS_CONNECTION_STRING}' \
-y -i=false
Verified by:
- variable list — shows the literal ${...} stored
- service exec ... -- env | grep DATABASE_URL — shows fully resolved value
```
The skill is updated to:
=signs) may still trigger Cobra parser issues, so verifying withvariable listafter the update is prudentThis is the same direction as #50, which removed the now-stale "variable update clears vars" warning from
zeabur-update-service.2. New section: zbpack build-time config via env vars
Adds documentation that zbpack reads env vars (via
ZBPACK_<SCREAMING_SNAKE_CASE>of the underlying config key) at build time. The most useful one for monorepos:ZBPACK_DOCKERFILE_PATH=infra/zeabur/api.Dockerfileper service.This replaces the need to swap a root
zbpack.jsonbetween deploys when the project has multiple services with different Dockerfiles. (See companion PR #56 for the full monorepo deploy story.)3. zeabur-database tip on custom URL schemes
Replace the stale
${}caveat with the corrected version, plus a tip: if your driver wants a non-default prefix (e.g. SQLAlchemy with psycopg3 wantspostgresql+psycopg://, notpostgresql://), construct the URL by interpolating the parts (${POSTGRES_USERNAME}, etc.) rather than reusing${POSTGRES_CONNECTION_STRING}which always usespostgresql://.Test plan
\${...}parts viavariable update -k(single-quoted) — verified storage viavariable listand resolution viaservice exec ... -- envzeabur deploy --service-idbuild came upplanType=dockerwith the right Dockerfile${POSTGRES_CONNECTION_STRING}always usespostgresql://prefix; constructingpostgresql+psycopg://requires interpolating parts🤖 Generated with Claude Code