Templates
Three independent reuse mechanisms — pipeline templates, repository templates, and organization templates.
There are three independent template mechanisms, each solving a different reuse problem — they are not variations of one system, and are not interchangeable.
Pipeline templates#
A snapshot of a job graph (PipelineTemplate.graph, the same JSON shape the visual editor edits directly), owned by a single user, saved from Pipelines → Editor's templates panel and re-loaded into the editor for any repository as a starting point. Renaming/deleting a saved template is available from the Templates page; editing the graph itself requires reopening it in the Editor, since that's the only place the graph-building UI exists.
Repository (file-tree) templates#
A snapshot of a specific repository's actual file contents at its default branch — not metadata, not a description of structure, the literal bytes:
- Settings → General → Save as template on a source repository reads its full tree recursively via the same code path repository browsing uses, and stores every file's content (UTF-8 text inline, binary content base64-encoded) as a JSON document (
RepoFileTemplate.files), capped at 500 files / 10MB total to keep it a scaffold rather than a general-purpose archive mechanism. - Templates → Use template creates a brand-new (initially empty) repository through the normal repository-creation path, then commits every stored file as that repository's first commit via the same
commitFileChanges→ real git push machinery any other server-initiated commit uses — meaning the new repository's first commit triggers the same post-receive hook, webhookPUSHevent, and CI trigger evaluation a human's first push would.
Because the source repository is only read once, at save time, a template survives the deletion of the repository it was captured from — it is a genuinely independent copy, not a live reference.
Organization templates#
Distinct from both of the above: an organization template describes the shape of a brand-new organization — which teams to create, which projects, and which repositories inside each project (each optionally seeded with a generated README/license/.gitignore, exactly like a manual repository creation would be). Applying one runs the normal organization/project/repository creation service calls in sequence — it is provisioning automation, not a content snapshot, and is the tool for "every new client engagement gets the same team structure," not "reuse this specific codebase's boilerplate" (that's what repository templates are for).