Your first build

Build it

bldr build site --name "first build"

You get a live tree of what the build is doing. --name is worth the habit: it is what you see in bldr builds afterwards, and "first build" reads better than a UUID.

The first run pulls the base image and runs your pod. The second run does neither:

bldr build site --name "again"

Nothing changed, so nothing ran. That is not a heuristic. Your member's content hashed the same, so the pod's inputs hashed the same, so bldr already had the answer.

Now change the HTML in .bldr.ts and build again. That pod runs, because its input is different. Nothing else does.

Get the files

A build produces content in the node's store. To put it on your disk, ask for an export:

bldr build --export site/site:./out --name "export the site"
cat out/index.html

--export <filter>:<path> writes the tree of the one target the filter matches to a path. The filter takes a target's full name, the member and then the target, so the site output of the site member is site/site. Naming an action also selects its target, so you do not have to ask for both.

Other things you can attach to a build:

See what else you could build

bldr build --no-targets --name "what is here"

That resolves your build code and reports every target the workspace declares without producing anything. It is the fastest way to ask "does my build code still work, and what does it think it can build".

Next: run it.