Context (ctx) Model
The context is a simple, read‑only bundle of values available when BPM renders files and runs your entry script. You reference it inside templates to keep paths and parameters consistent.
What’s In The Context
ctx.project: project information (e.g.,name).ctx.project_dir: absolute path to the project root (project mode) orNone(ad‑hoc mode).ctx.template: template information (e.g.,id,render.into,run.entry).ctx.params: all parameters resolved for this render/run.
Where Context Comes From
- Template defaults: from
template_config.yamlunderparams:. - Project state: from
project.yaml(project name/path and any saved params for prior runs). - CLI overrides: from flags like
--param key=valueonbpm template render/run.
Parameter precedence (lowest → highest):
- Defaults in
template_config.yaml→ values saved inproject.yaml→ CLI--paramflags.
How You Use It
You can access context values in two places:
- In rendered files (Jinja):
,. - In path templates (placeholders):
${ctx.project.name}/${ctx.template.id}/forrender.into.
Strict rendering: if a referenced value is missing, rendering fails with a clear error. This helps catch typos and missing params early.
Minimal End‑to‑End Example
1) project.yaml (created with bpm project init)
name: 250903_TEST
project_path: /abs/path/250903_TEST
2) templates/hello/template_config.yaml in your BRS
id: hello
description: Minimal demo template
params:
sample_id: "demo" # default; can be overridden
render:
into: "${ctx.project.name}/${ctx.template.id}/" # resolves under the project
files:
- run.sh.j2 -> run.sh
run:
entry: "run.sh"
publish:
sample_file: run.out
3) templates/hello/run.sh.j2 (Jinja)
#!/usr/bin/env bash
set -euo pipefail
echo "Sample: " > run.out
4) CLI (project mode)
cd /abs/path/250903_TEST
# Render with an override (CLI > project > defaults)
bpm template render --param "sample_id=NA12878" hello
# Run entry script in the rendered folder
bpm template run hello
# Optionally publish named outputs
bpm template publish hello
Results:
- Files render to
/abs/path/250903_TEST/250903_TEST/hello/(becauserender.intouses${ctx.project.name}/${ctx.template.id}/). run.shprints with the resolved parameter and writesrun.out.publishcan recordsample_file: <path-to-run.out>back to project state for discovery.
Communicating Via CLI, project.yaml, template_config.yaml
- CLI → Context: use
--param key=valueto setctx.params.keyfor this invocation. Use the active store and template id to pick which template to render/run. project.yaml→ Context: setsctx.project.nameand materializesctx.project_dirfromproject_path. It may store prior params and published outputs for repeatability.template_config.yaml→ Context: defines defaults (params), where to render (render.into), which files to render (render.files), and what to run (run.entry).
Tip: In ad‑hoc mode (bpm template render --out /tmp/out hello), ctx.project_dir is not used; the base becomes --out, and render.into is treated as . unless you explicitly change it.
That’s it: set params with the CLI, keep project identity in project.yaml, and author templates with template_config.yaml that read from ctx for reliable, repeatable runs.