Commands for services, calls, email and stored data

These commands change a feature flag while your app runs, show what your app sent outside while you develop it, the provider calls and the email, and check a deploy before it happens.

jadpo flags

Changes who gets which value of a feature flag while the app runs, and removes a flag from the source (Feature flags). flag is a synonym, and it takes --json.

• jadpo flags, or list, is a table of each flag: everyone's value, how many users are named, its shares, the day it last changed and its state: ○ default for a flag never changed, ● rolling out while callers get different values, ● true for everyone once one value holds, and ✓ ready to remove when it has held for seven days. A footer and, for the first flag ready to remove, its remove command follow. It succeeds whatever it lists.
• set <flag> [<value>] changes one part of the state and leaves the rest: with no option, everyone's value; --users <id>,… the named users'; --percent <n> one share, 0 removing the shares; --split <value>=<n>,… a share for each value. A Bool flag's value is true when an option is given without one. It shows what the flag gave before and gives now, who made the change and that every server has it within ten seconds.
• reset <flag> gives everyone the default: again; with --users it stops naming those users.
• remove <flag> --keep <value> rewrites the source as if the flag had always held that value, lists every change file by file, and checks the result, undoing it when it doesn't check (Flag rules: changing, listing, removing).

$ jadpo flags set new_checkout --percent 10✓ Set `new_checkout`    was       false for everyone (the default)    now       true for 10% of users; false (the default) for everyone else    logged    sam · role app_owner    applies   within 10 s, on every server

Each change writes a row of jadpo_flag_changes in the same statement, with the operator's name and the database role, as jadpo deliveries does. The database is --url's, the connection's setting's, or a running jadpo dev's; there is no --env flag. An unknown action, flag, value, user or share is cli.flags_arguments, with the nearest, and a database it can't read or a flag that changed meanwhile is flags.unavailable.

jadpo calls

Shows the provider calls jadpo dev made, faked or real. It takes --json. --connection, --operation and --request filter it.

• jadpo calls is a table of the last 500 calls, oldest first, each with its id, operation, source (generated, scripted, sandbox, recording), how it ended, its time and its request, then a footer and one hint.
• calls show <id> prints one call in full, laid out: what was sent, never its headers, and what came back.
• calls script <operation> <answer> sets the next answer for an operation: one of its failures' codes, or unavailable, lost, in_use or misconfigured. It checks the operation and the answer against the project first. calls script ai.<prompt> <condition> sets the next answer of a prompt asked through a package that fills ai, as one of ai.generate's five conditions (AI).

An unknown action, call, operation or answer is cli.calls_arguments, with the nearest (Debugging).

jadpo email

jadpo dev catches every email your app sends in a dev inbox, so nothing reaches a real address (Email). It takes --json.

• jadpo email is a table of the mail caught, oldest first, each with its id, email, address, subject and health. --to narrows it.
• email show <id> prints one with its text (--html for its HTML), its links numbered, its attachments, and each health problem with its fix.
• email links <id> numbers its links, and email open <id> <link> opens one in $BROWSER or the system's browser.
• email clear empties the inbox.
• email check-domain [<domain>] reads SPF, DKIM (--selector) and DMARC for the domain given, or for email: { from: }'s.

An unknown action, mail or link is cli.email_arguments, with the nearest. A browser that can't be started is email.browser_failed, with the link to open yourself.

jadpo runs unfinished

Run it against production before a deploy. It lists the unfinished multi-step runs and batches whose recorded path the new build changes, so an operator knows what will stop as diverged (Deploys). It takes --json.

--build takes the new build's id, b_ and twelve hex digits, as its stamp carries it (The build stamp) and the manifest lists it for each deployable. It must be the id of a build the checkout makes; cli.runs_arguments names the ones it does otherwise. It shows a table of each record whose build differs and whose action's step shape the build changes, so the record stops as diverged, or no longer keeps, so its steps are sent again. It also lists each running batch run whose call the build changes, which fails. A footer and one hint follow. --url and --store work as for jadpo deliveries (runs.unavailable).

Not built yet:

• jadpo services, with start, stop, restart <name>, logs <name> (--follow, --since) and shell <name>. It shows each container a package runs: its package, image, state, health, CPU and memory, restarts and uptime, and manages one. shell, a shell inside one, is for development only. In production they talk to the running app, never to the container engine (External services).
• jadpo dev grants add <connection> --owner <id>, which makes a fake OAuth grant for local development (OAuth grants).
• jadpo files ls, show, get, put and copy, which work on any store, in development or production, copy copying files between two stores (S3, R2, disk) (Files).
• jadpo batches list, show <id> and cancel <id>, which list batch runs (file reads and writes, batches.each) with their state and progress, show one run's progress and problems, and stop one, as batches.cancel does (Background work).
• jadpo search reindex, which rebuilds a search index from the database (Search).