Lifecycle specification

Update-Content Phase

Hooks driven by repository content — lockfiles, manifests, checked-in configuration — that restore dependencies once the workspace is synchronised.

Applies at
.devcontainer/lifecycle/update-content.d/
Status
Stable

01 Defines

The updateContentCommand phase: scripts in update-content.d/ that run after repository content is synchronised into the workspace during creation, and again when that content is refreshed, before final post-create setup.

02 Applies when

  • Dependencies are restored from a lockfile or manifest checked into the repository.
  • Derived content is regenerated from checked-in configuration or source files.
  • The work should rerun when workspace content is refreshed during creation or prebuilding.

03 Boundaries

  • User-home setup such as .zshrc, .npmrc, or cache directories belongs in on-create.
  • Background services and every-start runtime checks belong in post-start.
  • Interactive authentication and onboarding prompts are out of scope.

Expected behaviour

  1. 01
    Scripts are driven by repository state, not by the container or the developer.
  2. 02
    Scripts are idempotent and safe when content is synchronised again.
  3. 03
    Restores use the lockfile when one is present.

Behaviour#

Update-content is where the repository’s own files start to matter. It runs once the workspace content is available, and may run again when that content is refreshed during creation or prebuilding. Because the work is a function of the checked-in files, rerunning it after a content change brings the workspace back in line.

It sits between two easily confused neighbours. On-Create Phase prepares the container before content matters; Post-Create Phase finishes the workspace once everything is in place. Update-content is the step that responds to the content itself.

Good uses

  • npm ci or pnpm install --frozen-lockfile once the lockfile is available
  • dotnet restore once solution and project files are present
  • Downloading Hugo modules or regenerating derived site content

Avoid

  • User-home setup such as .zshrc, .npmrc, or cache directories
  • Background services or checks that must happen on every start
  • Interactive authentication or onboarding prompts

Examples#

This repository restores its pinned Node tooling here. It uses the lockfile when there is one and falls back to a plain install otherwise:

.devcontainer/lifecycle/update-content.d/10-install-node-dependencies.sh
#!/usr/bin/env bash
set -euo pipefail

if [ -f package-lock.json ]; then
	npm ci
else
	npm install
fi