view release on metacpan or  search on metacpan

doc/problem-report.md  view on Meta::CPAN

Regression reported 2026-10-10: when the host alias `somewhere` points to
`/tmp/foobar`, the in-container `d2 path add somewhere /workspace` inherited a
bind-mounted host config directory and rewrote the host alias to `/workspace`.
Expected: host `d2 paths` continues to show `/tmp/foobar`; only the container's
workspace command sees `/workspace`.

Red test and root cause: `t/91-cli-ticket-coverage.t` initially failed because
both container `exec` calls omitted config isolation; expected commands
required a private config-root override. Path configuration writes use the
regular active config mechanism, which previously pointed at the mounted host
config.

Fix: both in-container operations now pass
`DEVELOPER_DASHBOARD_CONFIG_OVERLAY=/dev/shm/developer-dashboard-workspace-config`
to Compose `exec`. This stores the alias in a private, additive container-local
config overlay, preserving existing settings while leaving the host
configuration untouched. A container smoke check added
`somewhere` at `/workspace` with an isolated config root and resolved it back
to `/workspace`. Red/green: the initial updated test failed on the old Compose
commands; after the fix, `d2 docker compose exec dev prove -lv
t/91-cli-ticket-coverage.t` passed all 212 assertions. The actual Compose smoke
used `d2 path add somewhere /workspace -o json` and then `d2 path resolve
somewhere` with the isolated config root. This repository has no `workspace`
service or mounted host-home fixture, so a full interactive workspace session
cannot be run here. The generated temporary container test directories were
removed after verification.

### Problem 47: Publish current master builds to Docker Hub (implementation complete; publication and external Scorecard gates pending)

Expected outcome: a GitHub Actions workflow triggered by pushes to `master`
(and by explicit manual dispatch) builds the current `master` checkout, logs in
to Docker Hub with the configured `DOCKER_HUB_USER` and `DOCKER_HUB_TOKEN`
secrets, and pushes both a `dist.ini` version tag and `latest`. The image must
be usable on Linux amd64 and arm64. Docker does not provide macOS-kernel
containers; Apple Silicon runs the arm64 Linux image through Docker Desktop's
Linux VM.

Reproduction: install from MetaCPAN, then compare the installed CLI with the
latest source on `master` before the next CPAN release. A Docker build that
installs only the MetaCPAN distribution will retain the older package even
though it is labeled as the current image.

Root cause: the normal install bootstrap is designed to fetch the published
CPAN distribution, while unreleased fixes exist only in the Git checkout. The
image flow had no job that rebuilt the checked-out code into a tarball and
installed that exact artifact after bootstrap.

Red test: `t/228-dockerhub-image-workflow.t` asserts the GitHub workflow,
credential wiring, version/latest tags, target platforms, and that the image
build runs `install.sh`, `dzil build`, and installs the generated tarball with
`cpanm`. It also guards that GitHub automation files, excluded from the CPAN
archive, do not make the packaged test suite fail, and that the shared Docker
context re-includes the tarball needed by the repository's local image build.

Implementation: `.github/workflows/dockerhub-image.yml` checks out `master`,
validates the X.XX distribution version, logs in to Docker Hub, and uses
Buildx/QEMU to publish a multi-platform manifest. Its Dockerfile runs
`install.sh`, installs the required Dist::Zilla plugins, builds the current
checkout, and tests/reinstalls the exact versioned tarball so an equal-version
MetaCPAN copy cannot shadow it. `.dockerignore` keeps local runtime state,
credentials, and build artifacts out of the image context. Detailed usage and
platform expectations are documented in the repository manual.

Verification: the full repository suite passed in the isolated Docker dev
container (259 files, 23,312 tests), with statement, subroutine, branch, and
condition coverage each measured at 100%. The Docker image build also passed;
its packaged cpanm install ran without `--notest` and passed (259 files, 16,985
tests), and an isolated Compose smoke test reported `d2 version` 5.81. The
focused release/security container gate passed (8 files, 6,438 tests), covering
web update/static/SSL checks, release metadata, this workflow contract,
kwalitee, POD syntax, and CPAN security metadata. `perlsec` was reviewed, and
the repository security scans and `git diff --check` passed. GitHub secrets are
only available to the configured `release` environment, so the remote
multi-platform Docker Hub publish cannot be exercised locally; it will run
when the workflow is pushed or manually dispatched. The first local image
attempt exposed that `.dockerignore` excluded the archive required by the
repository's `d2` image Dockerfile; a new failing assertion reproduced that
contract, then an exception rule fixed it. The next build passed and a fresh
isolated container reported 5.81. D2's project-layer `.env.pl` had also
selected the previous build marker as `D2D_VERSION`; providing the marker as
`D2D_LAST_BUILT_VERSION` made it select the current 5.81 archive without
editing local environment configuration. Host `dzil clean` followed by
`dzil build` completed successfully for 5.81; archive inspection confirmed
the new workflow contract test is included and no coverage database is
packaged. README/POD parity and all 76 library module versions were verified.

Post-push Scorecard identified one repository-fixable item: the Ubuntu base
image tag was not pinned by digest (Pinned-Dependencies 9/10). A new assertion
in `t/228-dockerhub-image-workflow.t` reproduced that finding before the
Dockerfile was changed to the Scorecard-reported multi-platform manifest
digest. This follow-up is version 5.82. The remaining Scorecard findings
require repository administration or community history; rerun Scorecard after
the next push and record the exact remaining gates. The 5.81 GitHub Docker Hub
workflow was triggered by the first push and its final result is being checked;
5.83 will run the multi-platform publish after the package and local image
gates pass and it is pushed.

Security review for Problems 46-47 (ASVS 5.0): V1, V4, V5, V7, V8, V10,
V11, V12, and V14 were applicable. The workspace service name is fixed, user
aliases remain argv values rather than shell source, the private overlay rejects
symlinks and non-owner directories, and startup/exec errors remain visible.
The image workflow requests read-only repository contents, pins every external
action to a full commit SHA and the Ubuntu base to its multi-platform digest,
and passes Docker Hub credentials only to the login action from the `release`
environment; credentials are not build arguments or context files. V2, V3, V6,
V9, and V13 (authentication, sessions, cryptography, transport, and application
API) have no changed runtime surface. OWASP A03, A04, A05, A08, and A09 were
reviewed for command construction, container reuse, workflow configuration,
source/image integrity, and visible failure reporting. A01, A02, A06, A07, and
A10 do not gain a changed access-control, cryptography, dependency, identity,
or request-forgery surface. Required security scans and web/static/SSL tests
passed in Docker; post-push Scorecard governance findings are tracked separately
from code-side security controls.

#### Problem 47 timeout correction (2026-10-10; release version 5.84)

Expected outcome: the GitHub multi-platform publish completes inside its
120-minute job limit and installs the current tarball into both runtime image
architectures. The full test and coverage gates still run before packaging;
image assembly must not repeat the full suite under QEMU.

Reproduction and root cause: pushed commit `aed8ab8d` triggered Actions run
`38078551920`. Setup, source checkout, version validation, QEMU/Buildx setup,
credential validation, and Docker Hub login all passed. The image build stayed
in progress until the configured 120-minute job timeout cancelled it. The
Dockerfile's final `cpanm` installation had no `--notest`, so it reran the
23,000+ test suite for each emulated target architecture despite the separate
full repository and coverage gates.

Red test: updated `t/228-dockerhub-image-workflow.t` first to require
`cpanm --notest --reinstall` for installing the generated archive. Running it
inside the Docker `dev` service failed at that assertion against the old
Dockerfile (31 passed, 1 failed), reproducing the unwanted duplicate suite.

Fix: the runtime image now installs the newly built, version-matched tarball
with `cpanm --notest --reinstall`. This does not weaken verification: full
repository and coverage gates remain mandatory, and the blank-container
integration gate installs the exact archive with tests enabled. The contract
test then passed all 32 assertions in the Docker `dev` service. The post-fix
5.84 full suite passed in Docker (`259` files, `23,284` tests); statement,
branch, condition, and subroutine coverage each measured `100.0%`. The focused
release/security/workflow gate passed `5,625` tests, and the required
web/static/SSL gate passed `459`. `dzil clean` and `dzil build` produced only
`Developer-Dashboard-5.84.tar.gz`; archive inspection confirmed 5.84, inclusion
of workflow/release tests, and no `cover_db`. The standard local image build
and a fresh one-off container both returned `d2 version` 5.84. A direct local
build of the workflow Dockerfile also completed and its one-off image returned
5.84. Finally, the blank Perl 5.44 Docker environment installed that archive
with cpanm tests enabled and completed the integration harness successfully.
The corrected 5.84 GitHub publish and post-push Scorecard remain pending this
version's push.

### Problem 46 follow-up: tmux cannot start in the Docker workspace (2026-10-11–12; runtime verified, packaging gates pending)

Expected outcome: `d2 workspace -c <alias> -d` must attach the caller's terminal
to a live tmux session running inside the Compose `workspace` container. The
session must use a socket location writable by the container user, and a later
`d2 workspace <alias> -c` must reconnect to that same session.

Reproduction: in a uniquely named Compose project, register host alias
`foobar` to the checked-out project and run `d2 workspace -c foobar -d` with the
workspace service running. Before the fix, the in-container command failed
after alias registration with `couldn't create directory /tmp/tmux-1000
(Permission denied)`. The container ran as uid 1000; its bound `/tmp` was mode
0755 and owned by root, so it was not writable. `/dev/shm` was mode 1777 and