view release on metacpan or  search on metacpan

lib/Developer/Dashboard.pm  view on Meta::CPAN

  dashboard docker compose --dry-run config

Include addons or modes:

  dashboard docker compose --addon mailhog --mode dev up -d
  dashboard docker compose config green
  dashboard docker compose config
  dashboard docker list
  dashboard docker list --disabled
  dashboard docker list --enabled
  dashboard docker disable green
  dashboard docker enable green

The resolver also supports isolated service folders without adding entries to
dashboard JSON config. If
C<./.developer-dashboard/config/docker/green/compose.yml> exists in the current
project it wins; otherwise the resolver falls back to
C<~/.developer-dashboard/config/docker/green/compose.yml>.
C<dashboard docker compose config green> or
C<dashboard docker compose up green> will pick it up automatically by
inferring service names from the passthrough compose args before the real
C<docker compose> command is assembled. If no service name is passed, the
resolver scans isolated service folders and preloads every non-disabled folder.
If a folder contains C<disabled.yml> it is skipped. Each isolated folder
contributes C<development.compose.yml> when present, otherwise C<compose.yml>.
To toggle that marker without creating or deleting the file manually, use
C<dashboard docker disable E<lt>serviceE<gt>> or
C<dashboard docker enable E<lt>serviceE<gt>>. The toggle writes to the
deepest runtime C<config/docker> root, so a child project layer can locally
disable an inherited home service by creating
C<./.developer-dashboard/config/docker/E<lt>serviceE<gt>/disabled.yml> and can
re-enable it again by removing that same local marker.
To inspect the effective marker state without walking the folders manually,
use C<dashboard docker list>. Add C<--disabled> to show only disabled
services or C<--enabled> to show only enabled services.

During compose execution the dashboard exports C<DDDC> as the runtime
C<config/docker> directory for the current runtime, so compose YAML can keep using
C<${DDDC}> paths inside the YAML itself. Project-local isolated services are
discovered from that same
C<./.developer-dashboard/config/docker/E<lt>serviceE<gt>/...> tree. Wrapper flags such as
C<--service>, C<--addon>, C<--mode>, C<--project>, and C<--dry-run> are
consumed first, and all remaining docker compose flags such as C<-d> and
C<--build> pass straight through to the real C<docker compose> command.
If one resolved service comes from an installed skill docker root, the
resolver also loads that skill's F<E<lt>skill-rootE<gt>/.env> file into the compose
environment before docker-config, addon, and mode env overlays are applied.
Only skills whose compose service files actually participate are included,
disabled skills are skipped, and F<E<lt>skill-rootE<gt>/.env.pl> is not executed from
this compose path. Nested skill services expand their env chain from the root
nested skill to the participating leaf service, preserving overwritten parent
keys under cumulative aliases such as C<foo_VERSION> and
C<foo_bar_VERSION> before the leaf value becomes the plain key. The resolver
also exports one skill-specific C<E<lt>skill-nameE<gt>_DDDC> variable for each
participating skill, using the leaf skill name with non-identifier characters
normalized to underscores and pointing that variable at the owning
F<config/docker/> root. Nested skill services additionally export the full
cumulative skill path alias such as C<foo_bar_zzz_DDDC> for the same compose
root, while the leaf alias stays available as C<zzz_DDDC>.
When C<--dry-run> is omitted, the dashboard hands off with C<exec> so the
terminal sees the normal streaming output from C<docker compose> itself
instead of a dashboard JSON wrapper.

=head2 Prompt Integration

Render prompt text directly:

  dashboard ps1 --jobs 2

C<dashboard ps1> now follows the original F<~/bin/ps1> shape more closely: a
C<(YYYY-MM-DD HH:MM:SS)> timestamp prefix, dashboard status and workspace info, a
bracketed working directory, an optional jobs suffix, and a trailing
C<🌿branch> marker when git metadata is available. The prompt helper reads the
branch directly from on-disk git metadata instead of shelling out to
C<git branch>, so repeated prompt renders stay lightweight on slower hosts such
as iSH. If the workspace workflow seeded C<WORKSPACE_REF> or the older
C<TICKET_REF> into the current tmux session, C<dashboard ps1> also reads that
context from tmux when the shell environment does not already export it, but it
skips that tmux probe entirely when the shell is not inside tmux.

Generate shell bootstrap:

  dashboard shell bash
  dashboard shell zsh
  dashboard shell sh
  dashboard shell ps

The generated shell helper keeps the same bookmark-aware C<cdr>, C<dd_cdr>,
C<d2>,
and C<which_dir> functions across all supported shells. C<cdr> first tries a
saved alias, then falls back to an AND-matched directory search beneath the
alias root or the current directory depending on whether that first argument
was a known alias. One match changes directory, multiple matches print the
list, and C<which_dir> prints the same selected target or match list without
changing directory. Bash still uses C<\j> for job counts, zsh refreshes
The shell-smoke regression coverage also compares those printed paths by
canonical identity, so macOS C</var/...> and C</private/var/...> aliases do
not fail equivalent C<pwd> / C<which_dir> checks. Bash still uses C<\j> for
job counts, zsh refreshes
C<PS1> through a C<precmd> hook with C<${#jobstates}>, POSIX C<sh> falls back
to a prompt command that does not depend on bash-only prompt escapes, and
PowerShell installs a C<prompt> function instead of using the POSIX C<PS1>
variable.

C<d2> is the short shell shortcut for C<dashboard>, so after loading the
bootstrap you can run C<d2 version>, C<d2 doctor>, or
C<d2 docker compose ps> without typing the full command name each time.

The same generated bootstrap also wires live tab completion for C<dashboard>
and C<d2>. Bash registers C<_dashboard_complete>, zsh registers
C<_dashboard_complete_zsh>, and PowerShell registers
C<Register-ArgumentCompleter> for both command names. Completion candidates
come from the live runtime instead of a hardcoded shell list, so built-in
commands, layered custom CLI commands, and installed dotted skill commands
all show up in suggestions. For bash, the generated helper captures
completion payloads first instead of relying on process substitution, which
keeps completion responsive on macOS and inside packaged install-test shells.
The generated bootstrap also wires C<cdr>,
C<dd_cdr>, and C<which_dir> completion. The first argument suggests saved
aliases plus matching directory names beneath the current directory, and later
arguments suggest matching directory basenames beneath the resolved alias root