Skip to main content
Version: 0.8.10

Add bootstrap and teardown scripts

Only if more than one worktree's app will run at a time. The assigner gives each issue its own worktree, which isolates the source tree and nothing else. A database, a cache, an uploads tree or a fixed port stays shared between every worktree until something provisions a per-worktree copy. That something is .jst/bootstrap.sh, and this task writes it. Why it matters, and how to decide what to isolate: Optional: parallel worktrees and Parallel instances.

What the scripts contain depends entirely on the kind of project, so this page doesn't give you a script. It gives you the contract, the example closest to your stack, and a task prompt that points the skills back at this page.

What the task produces​

filewho runs itwhen
.jst/bootstrap.sh (POSIX) / .jst/bootstrap.ps1 (Windows)jira-task-executor, step 1 — automatically, no promptonce per worktree, each time someone starts work in it
.jst/teardown.shyou, by hand — no skill runs itbefore git worktree remove

All three are tracked files, so every new worktree is born with them. Ship the .ps1 twin only if someone on the team runs Windows.

Pick the example closest to your stack​

your projectstart fromwhat it provisions
Python / tooling onlyPython toolchaina per-worktree venv/, nothing else
Frontend SPAReact / Vite SPAhost ports and node_modules
Services with stateMulti-service docker-composenetwork, database, media, certificates

The annotated example pair bootstrap.example.sh / bootstrap.example.ps1 is modelled on the docker-compose case. Take the shape from these, not the values.

The contract, in brief​

The executor exports five variables before it runs the hook:

variablevalue
JST_ISSUE_KEYthe issue key derived from the branch, e.g. PROJ-402
JST_WORKTREE_DIRabsolute path of this worktree's root
JST_BRANCHthe current branch, e.g. feature/PROJ-402-some-slug
JST_PARENT_BRANCHthe PR base from git config branch.<branch>.parentbranch; empty when unset
JST_PROJECT_KEYPROJECT_KEY from .jst/jira-sdlc-tools.env

Four rules make a hook that holds up:

  1. Fail-soft. A non-zero exit is reported and the executor carries on. Exit non-zero to mean "this worktree isn't runnable yet", and print how to finish the job by hand.
  2. Idempotent. A re-run of the executor re-runs the hook. Write every step as create-if-missing or reuse.
  3. Deterministic instance index. Derive ports, container names and data directories from one index computed from JST_ISSUE_KEY, never from "the next free slot", which two worktrees bootstrapping at once would race for. Index 0 is the main checkout.
  4. Runnable by hand. Give each variable a fallback equivalent to it, so you can debug the script outside the executor. For JST_ISSUE_KEY, extract the key from the branch name rather than using the whole branch.

Teardown undoes what bootstrap provisioned. In the worked examples, both scripts refuse to run in the main checkout, which holds the originals the copies were made from — copy that guard.

Full details: Setting it up — the worktree hook and project-config.md → the optional worktree hook.

Done when​

  • statuscheck's bootstrap row reports the script as present (it is INFO either way and never blocks).
  • Running .jst/bootstrap.sh twice in a fresh worktree succeeds both times, and the second run changes nothing.
  • Two worktrees can run their apps side by side without sharing the state you chose to isolate.
  • .jst/teardown.sh removes what bootstrap created and refuses to run in the main checkout.

Task prompt​

Paste this into your coding assistant from the main checkout. It names this page so the executor works from the contract rather than rediscovering it:

/jira-sdlc:jira-task-assigner "Add .jst/bootstrap.sh and .jst/teardown.sh so
several worktrees of this project can run at the same time. Follow
https://kantorv.github.io/jira-sdlc-tools/docs/step-by-step-installation/add-bootstrap-and-teardown-scripts
— the JST_* environment contract, fail-soft and idempotent, a deterministic
instance index from JST_ISSUE_KEY with 0 reserved for the main checkout — and
start from the worked example closest to this stack. Decide which state to
isolate per worktree (database, cache, storage, ports) and record that decision
in the script's header comment. Add .jst/bootstrap.ps1 only if the team uses
Windows."