Run-Parts Hook Directories

Behaviour#

The name comes from the classic Unix run-parts utility, which runs every script in a directory. Here the directory is chosen by event: post-start resolves to post-start.d/, on-create to on-create.d/, and so on. Adding a hook is adding a file; the devcontainer.json command never changes.

The canonical event names are initialize, on-create, update-content, post-create, post-start, and post-attach, one per phase of the Devcontainer Lifecycle . The runner enforces them through the directory check: an event with no matching directory is refused.

Ordering and failure#

Because the shell glob expands in lexical order, numeric prefixes make the sequence visible in a directory listing: 10-setup-devcontainer-tools.sh runs before 20-configure-zsh-profile.sh. Scripts that don’t depend on each other can share a prefix or use none.

Each hook is invoked as bash "$script", so it doesn’t need its executable bit set and doesn’t depend on its shebang. The runner itself runs under set -eu; when a hook exits non-zero, the runner exits at that point and the remaining hooks in the directory do not run.

Examples#

hooks_dir="$script_dir/$event.d"
if [ ! -d "$hooks_dir" ]; then
    echo "Lifecycle directory is missing for event: $event" >&2
    echo "Expected directory: $hooks_dir" >&2
    exit 1
fi

found_script=0
for script in "$hooks_dir"/*.sh; do
    if [ ! -f "$script" ]; then
        continue
    fi

    found_script=1
    script_name=${script##*/}

    echo "==> Running $script_name"
    bash "$script"
done

Running a phase by hand uses the same entry point as the container:

bash .devcontainer/lifecycle/run-parts.sh update-content