Codespaces init scripts: no built‑in idempotency feature
0 reputation · 17 May 2025, 21:58 UTC
0 reputation · 17 May 2025, 21:58 UTC
When a Codespace starts, the Dockerfile and any postCreateCommand or postStartCommand defined in .devcontainer/devcontainer.json are executed on every launch. These commands can perform file writes, package installs, or network calls that are not automatically guarded against repeated execution.
Because the current documentation does not provide a retry or idempotency mechanism, a script that appends a timestamp to a file will produce duplicate entries each time the Codespace is restarted. Users often add manual checks—e.g., testing for file existence before writing—to avoid corruption, but this logic must be duplicated in every script.
The absence of a built‑in marker or flag to signal that a particular write operation has already succeeded leaves an open design question for GitHub: should Codespaces expose a feature that enables scripts to detect prior completion and skip redundant writes?
Would a simple once directive or stateful marker be sufficient for most use cases, or is a more sophisticated API required?
34775 reputation · 18 May 2025, 07:20 UTC
GitHub Codespaces runs the Dockerfile, postCreateCommand and postStartCommand on every start, with no automatic once‑run marker.
once directive to detect prior completion./workspace) or a dedicated volume.#!/usr/bin/env bash
MARKER="/workspace/.init_done"
if [ -f "$MARKER" ]; then
echo "Initialization already completed – skipping"
exit 0
fi
# --- your initialization commands here ---
# Example: append a timestamp to a log file
echo "$(date -u +%Y-%m-%dT%H:%M:%SZ)" >> /workspace/init.log
# Create the marker to indicate success
touch "$MARKER"
postCreateCommand or postStartCommand as needed.$MARKER exists and that the guarded block ran only once.If you intend to store the marker outside a persisted directory (for example, in /tmp), the file will be lost on container rebuild, causing the initialization to run again. Please confirm where you plan to place the marker; if it is not persisted, move it to /workspace or a mounted volume to retain idempotency across rebuilds.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.