Skip to content

Fix dotfiles install (#45) and upgrade to PHP 8.4#48

Merged
kurowski merged 2 commits into
mainfrom
fix-dotfiles-cwd-and-php-8.4
May 29, 2026
Merged

Fix dotfiles install (#45) and upgrade to PHP 8.4#48
kurowski merged 2 commits into
mainfrom
fix-dotfiles-cwd-and-php-8.4

Conversation

@kurowski

@kurowski kurowski commented May 22, 2026

Copy link
Copy Markdown
Member

Summary

Test plan

  • dck && dce with --dotfiles-repository set against a fresh container — dotfiles clone succeeds, no exit 128.
  • ~/.devcontainer/.dotfilesMarker and ~/dotfiles/ both populated after first devcontainer up.
  • Container builds successfully on PHP 8.4 and Drupal app comes up (composer install, drush deploy, apache).
  • Spot-check that PHP extensions (mysqli, pdo_mysql, intl, gd, redis, zip) still load on 8.4.

🤖 Generated with Claude Code

kurowski and others added 2 commits May 22, 2026 11:45
Anchor lifecycle scripts to $WORKSPACE_FOLDER at entry and exit so the
shellServer's cwd stays valid for subsequent steps — including the
devcontainer CLI's own dotfiles install, which previously failed with
"Unable to read current working directory" after onCreate work
invalidated the inode the shellServer had cd'd into.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@kurowski kurowski merged commit 08afde3 into main May 29, 2026
1 of 2 checks passed
@kurowski kurowski deleted the fix-dotfiles-cwd-and-php-8.4 branch May 29, 2026 19:54
kurowski added a commit that referenced this pull request Jun 9, 2026
The cd "$WORKSPACE_FOLDER" appended to devcontainer_on_create and
devcontainer_post_create in #48 was meant to leave the devcontainer
CLI's persistent shellServer in a valid cwd before the dotfiles clone.
It can't: each lifecycle command runs in its own `/bin/sh -c` exec that
exits as soon as the function returns, so the cd never touches the
shellServer. The real fix is anchoring the image WORKDIR (prior commit).

Kept _cwd_workspace at the top of each script — on_create's docroot
symlink (ln -s "$(pwd)/web" ...) depends on a deterministic cwd, so that
call is load-bearing, not part of the broken cwd-restore theory.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
kurowski added a commit that referenced this pull request Jun 9, 2026
The php base image leaves WORKDIR at /var/www/html, which
devcontainer_on_create.sh deletes and replaces with a symlink to the
mounted docroot. The devcontainer CLI starts its persistent setup shell
("shellServer") in WORKDIR with no -w flag, so that rm -rf orphans the
shell's cwd. The later dotfiles `git clone` runs in the same shellServer
and fails its getcwd() with "Unable to read current working directory".

The lifecycle commands run as separate execs (-w workspaceFolder), so
the cd "$WORKSPACE_FOLDER" added in #48 can't repair the shellServer.
Anchoring WORKDIR to /home/vscode keeps the shellServer's cwd valid
through the docroot swap.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Dotfiles install fails with "Unable to read current working directory" after lifecycle scripts run

1 participant