Edit a pipeline's kernel code
A run_code node runs a kernel — the code process(item, ctx) that does the node's
actual work. This guide walks the loop for editing that code from the CLI: pull it, test it
locally against the same harness the platform uses, and push it back as a new version.
1. Pull the code
Pull a pipeline's pinned kernels into local files:
blazerops code pull my-pipeline -o .
This writes each node's kernel under kernels/<node>/ and a kernels.lock recording the
versions you pulled. (blazerops export my-pipeline pulls the whole pipeline — the
pipeline.toml and its kernels — if you also want to edit the graph.)
2. Edit the kernel
Edit kernels/<node>/kernel.py. A kernel is a per-unit function plus a SHAPE
declaration; keep the domain logic in process(item, ctx) and let the declaration describe
what it reads and emits. See Harness, kernel & config
for the full contract.
3. Test it locally
Run the kernel through the same harness the platform uses, on a sample input:
blazerops kernel test kernels/<node> -i sample/
This is the same code path, image, and input contract as a real run — so a kernel that passes here behaves the same at corpus scale. It writes a local test manifest that the next step checks for.
4. Push it back
Push your edited kernels. Each becomes a new version (append-only), is registered, and
is repinned in your local pipeline.toml:
blazerops code push -m "fix the label mapping"
code push refuses untested code — if a kernel has no passing local test result, it stops
rather than register an unproven body. It also refuses a stale base, so you cannot overwrite
a version someone else pushed in the meantime.
5. Validate and push the pipeline
Pushing code repins your local pipeline.toml. Validate and push the pipeline so the new
versions take effect:
blazerops validate
blazerops push
Recap
code pull → edit → kernel test → code push → validate && push. Each kernel edit is a
new, registered version; local testing runs the real harness, so what passes locally is what
runs in production.