Bundle

puppi build turns a pipeline into a deployment. A deployment is two files: bundle.js, the pipeline in one JavaScript file, and manifest.json, the description of that pipeline.

The manifest lists assets, dependencies, schemas, checks, schedules, and connection declarations. A connection declaration carries a type and a config shape. It does not carry a password. Any connector client the config registered is included in bundle.js.

Build the project

puppi build

The command writes both files into the directory out names. The default is dist. It also writes puppi-env.d.ts next to puppi.config.ts. That file maps each asset key to its row type, so ctx.input("typo/key") is a type error after the first build. Keep puppi-env.d.ts out of version control. The project’s tsconfig.json has to include it, or the editor ignores it.

The build prints each asset, its role, and the assets it reads.

What the build records

The CLI loads the bundle and runs the top-level source(), model(), destination(), and group() calls. Those calls register assets. Their run functions are not called. Code at the top of the pipeline has to be safe to execute during the build. A loop that calls source() is fine. A network request at the top level runs during the build.

The CLI then reads each producer for ctx.input("…") and ctx.connection("…") calls whose argument is a string literal. A literal ctx.input("demo/customers") becomes a dependency. A key built in a variable is invisible to that pass. Put that key in the asset’s deps or connections array. Those arrays are added to the literals. Leaving a literal out of deps does not remove it.

Each asset gets a code_version, a hash of its definition and of its producer source. Changing one asset’s function changes that asset’s version. The other assets keep theirs. The engine uses this to notice that the code behind a stored result has changed. See Staleness.

What the engine keeps

The engine stores the bundle by its content hash. A second deploy of the same bytes uploads nothing. The manifest points at sha256:<hash>. A deployment that names a hash the engine does not have is rejected.

The same bundle can be deployed to more than one environment. Each environment gets its own deployment row and its own pointer. See Deploy and rollback.