DAY_LOCAL | Make day new scaffolds depend on a local day checkout instead of the git remote (CI) |
DAY_THEME | light | dark — forces the app’s theme on every backend (AppKit appearance, libadwaita color scheme, Qt 6.8+ color scheme, UIKit interface style, Android night mode, XAML element theme, OHOS color mode); unset = follow the system. CI’s themed screenshot cycles pass it via day launch --env. An app that applies its own persisted appearance at startup must honor the env-wins rule (docs/prefs.md): skip the boot application when DAY_THEME is set, or the app clears the forced theme right back; day-piece-settings::apply_startup does this for you, and Day Showcase’s hand-rolled menu plumbing shows the guard (src/commands.rs) |
DAY_WINDOW | <width>x<height> (e.g. 700x850) — overrides the app’s initial window size for responsive-layout testing on desktop backends; mobile/web size to the screen and ignore it |
DAY_CAPTURE_SIZE | <width>x<height>[@<scale>] in pixels, or window — read by day launch --script: what the run captures desktop-class targets at, over Day.toml [screenshots] and under --capture-size (website docs “dayscript”, “Capture size”) |
DAY_CAPTURE_SCALE | the scale a window snapshot is rendered at (2) — set by day launch --script from the capture size; honored by the backends that render their own snapshot (GTK, Qt), and on GTK and XAML it also marks the window size as the size of the CAPTURE rather than of the window around it |
DAY_CAPTURE_DISPLAY | native or virtual — read by day launch --script on macOS: never, or always, create the HiDPI virtual display a macos-appkit capture uses when no attached display has the capture’s scale. Unset decides by the displays attached |
DAY_WINDOW_SCREEN | a CGDirectDisplayID — macos-appkit opens its window on that display; set by day launch --script to the capture display it created |
DAY_WEB_DRIVER_VIEWPORT | <width>x<height>[@<scale>] in points — the bundled web driver’s viewport and device scale factor; set by day launch --script from the capture size, default 1280x800@2 |
DAY_APP_VERSION, DAY_SCRIPT | The app’s version and the driving script’s file name, set by day launch on every run. A debug build appends them to every window title as (version/toolkit[/script]) — docs/windows.md. Release builds ignore both |
ANDROID_SERIAL | adb’s standard device nav host; when set, day build/launch and dayscript sessions target only that device instead of every connected one |
DAY_LOG_ACTIONS | 1 narrates every user action to stdout in the dayscript vocabulary (dayscript ▸ tap inc "Add") without recording anything, the same lines a recording echoes (§14.6). An app can also call day::record::log_actions(true); Day-Showcase does, and reads DAY_LOG_ACTIONS=0 as the way to silence it |
DAY_VERBOSE | 1 | true — the global --verbose flag, from the environment: every day command forwards its sub-commands’ raw output (cargo, gradle, xcodebuild, hvigor, adb, codesign, …) instead of capturing it. One env: line turns a whole CI job verbose, including invocations no flag can reach (the launches a generated dayscript runner performs). An explicit --verbose on the command line also turns it on; any other value (or unset) leaves the default quiet output |
DAY_SCRIPT_MAIN_TIMEOUT_SECS | How long one dayscript step waits for the app’s main thread before failing (default 30). This is not the step’s implicit-wait budget; it covers a main thread that has not answered at all, which is a property of the machine (a shared CI vCPU compositing its first frame) rather than of the script. Raise it on a slow runner |
DAY_SIGN_STORE_PASS, DAY_SIGN_KEY_PASS | The keystore and key passwords day sign apply --keystore signs with. They live here rather than in the argument list, which every other process on the machine can read, and they are what lets a distributor sign a package without the project that built it (docs/packaging.md) |
DAY_FLAVOR | The build flavor to apply, the global --flavor flag from the environment: day build, every scripted launch and day pack read Day-<name>.toml as a layer over Day.toml (docs/flavors.md). One env: line builds a whole CI matrix leg as the flavor, and the value crosses into the xcodebuild and gradle callbacks so the identity they write is the flavor’s |
DAY_RESOURCE_ROOT | The resource tree day-build reads in the app’s build.rs, in place of <project>/resource. Set by day build --flavor to the merge of the app’s tree and the flavor’s overlay, under build/day/flavors/<name>/resource; unset for a plain build |
DAY_SELF_COMMAND | How day mcp-server re-invokes the CLI for each tool call, as a JSON array of argv[0] plus any leading arguments (["cargo","run","--manifest-path","…/Cargo.toml","-q","-p","day-cli","--"]). Unset, a tool call runs the server’s own executable. The VS Code extension sets it when day.cliSource points at a day checkout, so an edit to day-cli reaches the agent’s tools the same way it already reaches the editor’s Build and Run — see docs/agent.md. An unusable value falls back to the default rather than failing every tool |
DAY_SIGN_*, DAY_NOTARY_*, DAY_ASC_*, DAY_KS_PASS, … | Release-signing secrets referenced from Day.toml’s [signing] tables via ${VAR}; resolved at pack time, degrade to the dev signing tier when unset (§20) |