Covers two scenarios on a single Kind cluster: - Single-repo: deploy create copies commands.py into hooks/, deployment start runs it, mutating the stack-source working tree to v2 + deployment restart re-copies and re-executes v2. - Multi-repo: stack with two pod repos produces hooks/commands_0.py + commands_1.py, deployment start invokes both pod start() hooks. The test stages stack files into a temp git clone (bare + working) so restart's git pull has a real upstream. busybox pods keep the harness trivial. Phase 2 uses kubectl wait directly because deployment ps's substring filter (deploy_k8s.py:1366) doesn't list multi-pod stacks. Also tightens the _copy_hooks docstring to spell out that only call_stack_deploy_start loads from the copied location. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| deploy | ||
| README.md | ||
| stack.yml | ||
README.md
test-restart-hook
E2E test stack used by tests/k8s-deploy/run-restart-hook-test.sh.
The stack ships a single start() hook that writes a versioned marker file
into the deployment directory. The test:
deploy create→ assertscommands.pywas copied into<deployment>/hooks/.deployment start→ asserts the marker file contains the v1 string.- Modifies
commands.pyin the stack-source working tree (v1 → v2). deployment restart→ asserts the new commands.py was re-copied into<deployment>/hooks/and the marker file now contains the v2 string.
The pod uses a public busybox image that just sleeps; the start hook is the
only thing under test.