dirigent-examples 0.15.0__py3-none-any.whl

dirigent_examples/shelves/demo/markdown-showcase.yaml

@@ -0,0 +1,117 @@
+# A description that exercises every markdown construct the UI claims to render.
+#
+# A pipeline's description is long-form and markdown-capable, and it is the body of the
+# pipeline's screen. Most examples use one paragraph of it. This one uses all of it, so that
+# a renderer change has something to fail against: headings, both kinds of list, nested
+# items, a task list, inline code, a fenced block with a language, a fenced block without
+# one, a table with alignment, a blockquote, a horizontal rule, emphasis, a link, and a long
+# paragraph that has to wrap.
+#
+# It is a real pipeline rather than a stub, because a document that cannot run has no
+# business in examples/ -- the two steps below reshape a small payload and need no network
+# and no allowlist entry. The description is the exhibit; the steps are what make it legal.
+#
+# The rendering rule the corpus follows: a screen's title is the name if there is one and
+# the code otherwise, the code is always on screen in mono and never drawn twice, and the
+# description is the body. So this document carries all three, and the body is what to look
+# at.
+#
+#   dg run --local examples/demo/markdown-showcase.yaml
+#   dg pipelines show markdown-showcase          # the description, rendered
+
+format: dirigent/v1
+kind: pipeline
+code: markdown-showcase
+name: Markdown showcase
+description: |
+  A pipeline whose **description** is the point. Everything below is one markdown document,
+  rendered as the body of this pipeline's screen.
+
+  ## Headings, and what they are for
+
+  A description long enough to need sections should have them. This is an `h2`; the format
+  puts no ceiling on depth, and a renderer is expected to keep the hierarchy visible.
+
+  ### A third level
+
+  Which exists mainly so the scale between levels can be judged.
+
+  ## Lists
+
+  Unordered, with a nested level:
+
+  - Extract, from a source that may or may not be awake
+  - Reshape, which is where most of the work actually is
+    - `transform.jq` for one whole value
+    - `map.jq` for one element at a time
+    - `filter.jq` when the answer is a shorter list
+  - Load, and then say so
+
+  Ordered, because order sometimes matters:
+
+  1. Apply the document
+  2. Run it once by hand
+  3. Only then give it a clock
+
+  ## Code
+
+  Inline code such as `dg run markdown-showcase --watch` sits inside a sentence. A fenced
+  block with a language gets highlighted:
+
+  ```bash
+  dg apply examples/demo/markdown-showcase.yaml
+  dg run markdown-showcase --watch
+  ```
+
+  And one without a language does not, which is the correct treatment for output:
+
+  ```
+  {"kind": "run", "status": "succeeded", "duration_ms": 412}
+  ```
+
+  ## A table
+
+  | Block | Reads | Writes | Needs the allowlist |
+  | --- | :---: | ---: | --- |
+  | `transform.jq` | one value | one value | no |
+  | `http.request` | a URL | an inline body or storage | no |
+  | `shell.run` | a command | stdout and stderr | **yes** |
+  | `storage.copy` | a URI | a URI | no |
+
+  ## A quote, and a rule
+
+  > A run is a row, not a process. It survives every restart, and it is queryable long
+  > after the machine that executed it is gone.
+
+  ---
+
+  ## Emphasis, links, and wrapping
+
+  Text can be *emphasised*, **strong**, or ***both at once***, and it can carry a link to
+  [the transforms page](../docs/transforms.md). This last paragraph is deliberately long so
+  that soft wrapping has something to do with it: a description is written as prose in a
+  file where the lines are hard-wrapped at a sensible width for reading in an editor, and
+  it must arrive on screen as one flowing paragraph rather than as a column of short lines,
+  because the editor's line breaks are an accident of the file and not a fact about the
+  text.
+
+tags: [demo, transform]
+
+requires:
+  blocks:
+    - transform.jq
+
+steps:
+  collect:
+    block: transform.jq
+    config:
+      input:
+        constructs: [headings, lists, code, table, quote, rule, emphasis]
+      program: "{counted: (.constructs | length), constructs: .constructs}"
+
+  summarise:
+    block: transform.jq
+    depends_on: [collect]
+    config:
+      input: "${steps.collect.output.value}"
+      program: "{note: \"\\(.counted) markdown constructs, all of them in the description\"}"

dirigent_examples/shelves/demo/params-showcase.yaml

@@ -0,0 +1,92 @@
+# The parameter schema is plain JSON Schema, and it is load-bearing in three places.
+#
+# It validates every run's parameters, whoever started it: the CLI, the API, a schedule's
+# overrides, or a webhook's mapped payload. It is what the UI renders the run dialog from,
+# so an enum becomes a select and a date format becomes a date picker without any UI code
+# knowing this pipeline exists. And apply checks every ${params.x} in the document against
+# it, so a typo is caught when the document is applied rather than when it fires at 05:00.
+#
+# Defaults are filled in before validation, so a parameter with a default is optional.
+#
+# The CLI reads the schema before it sends anything, so a value is coerced to the type the
+# schema declares. Three ways to pass parameters, all ending in the same validated object:
+#
+#   dg run --local examples/demo/params-showcase.yaml -p day=2026-01-01 -p dataset=climate
+#
+#   # dotted keys address a nested leaf, and the declared type decides the coercion:
+#   #   batch_size is an integer, so -p batch_size=1000 sends 1000, not "1000"
+#   dg run --local examples/demo/params-showcase.yaml \
+#     -p day=2026-01-01 -p dataset=climate -p batch_size=1000 -p dry_run=true
+#
+#   # an array or an object is given whole, inline, in JSON or YAML:
+#   dg run --local examples/demo/params-showcase.yaml \
+#     -p day=2026-01-01 -p dataset=climate -p regions='[east, west, north]'
+#
+#   # or a whole payload from a file, with flags overriding it:
+#   dg run --local examples/demo/params-showcase.yaml -P params.yaml -p dataset=incidence
+#
+# Array indices are not addressable from a dotted key: -p regions.0=east and
+# -p regions[0]=east are both refused, because a dotted path cannot tell an index from an
+# object key named "0", and brackets are reserved in case element addressing is ever added.
+
+format: dirigent/v1
+kind: pipeline
+code: params-showcase
+name: Every parameter shape
+description: Everything a run form is built from, in one parameter schema.
+
+tags: [demo, http]
+
+params:
+  type: object
+  required: [day, dataset]
+  properties:
+    day:
+      type: string
+      description: The logical date this run covers.
+      format: date
+
+    dataset:
+      type: string
+      description: Which dataset to process.
+      enum: [climate, population, incidence]
+
+    regions:
+      type: array
+      description: Regions to process; every one becomes its own run item.
+      default: [east, west]
+      items:
+        type: string
+
+    batch_size:
+      type: integer
+      description: How many records to send per request.
+      default: 500
+      minimum: 1
+      maximum: 10000
+
+    dry_run:
+      type: boolean
+      description: Validate the payload without writing anything downstream.
+      default: false
+
+steps:
+  process:
+    block: http.request
+    # The fan-out is over a parameter, so how wide the run is is decided when it starts
+    # rather than when the document is written.
+    for_each: "${params.regions}"
+    items: continue
+    config:
+      url: https://postman-echo.com/post
+      method: POST
+      query:
+        day: "${params.day}"
+        dataset: "${params.dataset}"
+        region: "${item}"
+        batch_size: "${params.batch_size}"
+        dry_run: "${params.dry_run}"
+      body:
+        day: "${params.day}"
+        dataset: "${params.dataset}"
+        region: "${item}"

dirigent_examples/shelves/demo/requires.yaml

@@ -0,0 +1,65 @@
+# The requires preflight, and referencing a connection by name.
+#
+# Documents are portable because everything is referenced by name -- block ids, connection
+# names, other pipelines -- and never by id. That portability only works if applying a
+# document to an instance that is missing something says so once, with the whole list,
+# rather than one unknown-block error at a time.
+#
+# apply checks requires first: everything named here must exist on the target instance.
+#
+# The connection carries the credentials, and the document carries only its name. Create it
+# once on a server:
+#   dg connection create http postman-echo --set base_url=https://postman-echo.com
+#
+# Or hand it to a local run, which has no server to hold it:
+#   dg run --local examples/demo/requires.yaml --connections examples/connections.yaml
+
+format: dirigent/v1
+kind: pipeline
+code: requires
+name: Declared requirements
+description: Declare the blocks and connections this document cannot run without.
+
+tags: [demo, http, storage]
+
+requires:
+  blocks:
+    - http.request
+    - storage.write
+    - storage.copy
+  connections:
+    - postman-echo
+
+steps:
+  authenticate:
+    block: http.request
+    config:
+      # The connection holds the base URL and the credential, so the document names a path
+      # and never a secret. What is stored is which connection, not what is in it.
+      connection: postman-echo
+      path: /basic-auth
+      method: GET
+
+  publish:
+    block: http.request
+    depends_on: [authenticate]
+    config:
+      connection: postman-echo
+      path: /post
+      method: POST
+      body:
+        authenticated: "${steps.authenticate.output.status}"
+
+  receipt:
+    block: storage.write
+    depends_on: [publish]
+    config:
+      target: "${run.scratch}/reports/receipt.json"
+      value: "${steps.publish.output.body}"
+
+  archive:
+    block: storage.copy
+    depends_on: [receipt]
+    config:
+      source: "${steps.receipt.output.uri}"
+      target: "${run.scratch}/archive/receipt.json"

dirigent_examples/shelves/demo/weekly-import-malawi.yaml

@@ -0,0 +1,54 @@
+# The other half of the shared-name pair; weekly-import-nepal.yaml carries the explanation.
+#
+# Both documents declare `name: Weekly import`. Applying both leaves an instance holding two
+# pipelines with the same title and different codes, which is exactly the situation the
+# naming rules allow and the screens are drawn to survive.
+#
+# Kept as a separate file because a dirigent document holds exactly one pipeline. That is
+# also why composition is two files, and why a schedule example carries its own pipeline.
+#
+#   dg apply examples/demo/weekly-import-malawi.yaml
+#   dg run weekly-import-malawi -p week=2026-W02
+
+format: dirigent/v1
+kind: pipeline
+code: weekly-import-malawi
+# The same title as weekly-import-nepal.yaml, on purpose.
+name: Weekly import
+description: |
+  The Malawi half of a deliberately ambiguous pair.
+
+  Same display name as `weekly-import-nepal`, different `code`. The listing shows one title
+  twice and two codes once each, which is how a person tells them apart and how every
+  reference already did.
+
+tags: [demo, transform]
+
+requires:
+  blocks:
+    - transform.jq
+
+params:
+  type: object
+  properties:
+    week:
+      type: string
+      description: The ISO week being imported.
+      default: 2026-W01
+
+steps:
+  read_manifest:
+    block: transform.jq
+    config:
+      input:
+        country: malawi
+        week: "${params.week}"
+        districts: [balaka, chikwawa, dedza, karonga, mzimba, salima, zomba]
+      program: "{country, week, districts: (.districts | length)}"
+
+  summarise:
+    block: transform.jq
+    depends_on: [read_manifest]
+    config:
+      input: "${steps.read_manifest.output.value}"
+      program: "{note: \"\\(.country) \\(.week): \\(.districts) districts imported\"}"

dirigent_examples/shelves/demo/weekly-import-nepal.yaml

@@ -0,0 +1,75 @@
+# Two pipelines, one display name, and only the code telling them apart.
+#
+# This document and weekly-import-malawi.yaml both carry `name: Weekly import`. That is legal,
+# it is not a mistake, and an instance holding both is behaving correctly.
+#
+# The four fields every addressable thing carries each have exactly one job:
+#
+#   id           the uuid a machine holds
+#   code         the addressable key: constrained, unique, and what a URL, a reference and
+#                `dg run` all carry
+#   name         an optional human title, free-form, with NO identity semantics at all --
+#                nothing may ever be referenced by it, and two rows may share one
+#   description  the long-form body
+#
+# The temptation this pair exists to head off is treating a name as a key: looking a pipeline
+# up by it, keying a dictionary on it, or assuming a listing's titles are distinct. Names are
+# for reading. `dg run weekly-import-nepal` names a pipeline; "Weekly import" names two, and
+# an instance asked to run that has no way to choose.
+#
+# So the UI's rule pays for itself here. A screen shows the name as the title AND the code in
+# mono beside it, always, never drawn twice -- which is what makes two identically titled
+# rows in a listing tellable apart at a glance instead of a support question. Apply both and
+# look at the pipelines list.
+#
+# Nothing here reaches the network or runs code on the worker.
+#
+#   dg apply examples/demo/weekly-import-nepal.yaml
+#   dg apply examples/demo/weekly-import-malawi.yaml
+#   dg pipelines list                             # two rows, one title, two codes
+
+format: dirigent/v1
+kind: pipeline
+code: weekly-import-nepal
+# Shared, deliberately, with weekly-import-malawi.yaml. The code above is what differs, and
+# the code is the only thing that was ever identity.
+name: Weekly import
+description: |
+  The Nepal half of a deliberately ambiguous pair.
+
+  This pipeline and `weekly-import-malawi` share the display name **Weekly import**. Only
+  the `code` is identity: `name` is free-form, carries no uniqueness, and nothing may be
+  referenced by it.
+
+  Two rows may share a title. Neither may share a code.
+
+tags: [demo, transform]
+
+requires:
+  blocks:
+    - transform.jq
+
+params:
+  type: object
+  properties:
+    week:
+      type: string
+      description: The ISO week being imported.
+      default: 2026-W01
+
+steps:
+  read_manifest:
+    block: transform.jq
+    config:
+      input:
+        country: nepal
+        week: "${params.week}"
+        districts: [bagmati, gandaki, karnali, koshi, lumbini, madhesh, sudurpashchim]
+      program: "{country, week, districts: (.districts | length)}"
+
+  summarise:
+    block: transform.jq
+    depends_on: [read_manifest]
+    config:
+      input: "${steps.read_manifest.output.value}"
+      program: "{note: \"\\(.country) \\(.week): \\(.districts) districts imported\"}"

dirigent_examples/shelves/docker/README.md

@@ -0,0 +1,29 @@
+# Docker examples
+
+The `docker.*` family runs containers on the worker, which is why each block needs its id in
+`DIRIGENT_ENABLED_UNSAFE_BLOCKS` before an instance will run it, and a daemon the worker can
+reach. [docs/docker.md](../../docs/docker.md) is the family's home, and
+[docs/security.md](../../docs/security.md) says what mounting the socket grants.
+
+```bash
+dg run --local examples/docker/docker-hello.yaml --enable-unsafe docker.run
+```
+
+The last two documents on the shelf **fail on purpose**: they are here for what a broken
+stack and a failed drive step leave behind, which in both cases is nothing.
+
+## Pipelines
+
+| File | What it teaches |
+| --- | --- |
+| [docker-hello.yaml](docker-hello.yaml) | One command in one container: the image pulled first, no network, the streams collected. |
+| [docker-ticker.yaml](docker-ticker.yaml) | The live log: a container talking while it works, each probe appending what arrived since the last one. |
+| [docker-compose-stack.yaml](docker-compose-stack.yaml) | A whole stack: `docker.compose.up` brings it up, a `docker.run` step joins its network, and `docker.compose.down` with `rule: all_done` tears it down on any outcome. |
+| [docker-compose-database.yaml](docker-compose-database.yaml) | A database driven for real: `wait: true` turns a healthcheck into a gate, a `psql` container writes and reads rows, and the volumes go with the teardown. |
+| [docker-compose-file.yaml](docker-compose-file.yaml) | The other compose form: a file an earlier step wrote into the run's work directory, named by its path relative to it. |
+| [docker-compose-profiles-env.yaml](docker-compose-profiles-env.yaml) | Parameters reaching the stack: a variable compose interpolates, and a profile that decides whether the optional service exists. |
+| [docker-build-run.yaml](docker-build-run.yaml) | An image built on the worker and run by tag, because a built image lives only in the store of the daemon that built it. |
+| [docker-build-push.yaml](docker-build-push.yaml) | Pushing what was built: a `docker` connection holding a registry credential, and the tags and digests that come back. |
+| [docker-remote-daemon.yaml](docker-remote-daemon.yaml) | Naming the daemon: a `docker` connection with a host and its client TLS, on every step of one stack's lifecycle. |
+| [docker-compose-failing-up.yaml](docker-compose-failing-up.yaml) | A bring-up that fails, and the containers it does not leave behind: the block tears its own half-built project down. |
+| [docker-run-failing-teardown.yaml](docker-run-failing-teardown.yaml) | A drive step that fails: the run is failed, the teardown ran anyway, and the daemon holds nothing. |

dirigent_examples/shelves/docker/docker-build-push.yaml

@@ -0,0 +1,110 @@
+# Building an image and pushing it, which is the one thing a tag alone cannot do.
+#
+# docker-build-run.yaml builds an image and runs it on the same worker, where the tag is the
+# whole contract and the image never leaves that daemon's store. This document is the other
+# half: the image is pushed, so a later run on another worker, another cluster or another
+# machine can pull it by name.
+#
+# IT CANNOT RUN WITHOUT A REGISTRY. There is no public registry that will take an anonymous
+# push, so this document does nothing at all until it has a real registry and a credential
+# for it. Create the connection once, with a token that may write packages:
+#   dg connection create docker ghcr \
+#     --set registry=ghcr.io \
+#     --set username=your-account \
+#     --set "password=$GITHUB_TOKEN"
+#
+# docker.build declares local_execution, so the engine refuses it unless the instance
+# allowlists its id:
+#   export DIRIGENT_ENABLED_UNSAFE_BLOCKS='["docker.run","docker.build"]'
+#
+# PUSHING NEEDS A CONNECTION AND SAYS SO. push: true with no connection is refused when the
+# document is applied, not when it first runs, and a connection carrying no username and
+# password is refused when the step starts. Neither is a build that silently produced a local
+# image nobody can reach.
+#
+# ONE DAEMON, THEREFORE ONE WORKER. The build and the step that wrote its context are on the
+# worker's own filesystem, so requires.workers keeps them on one docker-capable worker. The push
+# is what frees the image from that worker: once it is in the registry, anything can pull it.
+#
+# THE CREDENTIAL NEVER BECOMES AN ARGUMENT. The password is sealed on the connection, reaches
+# `docker login` on stdin, and lives in a DOCKER_CONFIG directory of its own under the run's
+# work directory -- never the worker's own docker config. The step logs out and the directory
+# goes when it leaves, so nothing about the login survives the step, and the password is
+# scrubbed out of every log line and every failure message.
+#
+# THE TAG IS A REGISTRY ADDRESS NOW. A pushed tag is fully qualified: registry, owner, name.
+# The build's output says which tags reached the registry (pushed) and the digest the registry
+# gave each of them (digests), and a digest is the only exact name for what was pushed -- a
+# tag can be moved, a digest cannot.
+#
+# TO MAKE IT YOURS: point image_tag at your own registry and repository, replace the Dockerfile
+# the first step writes with your own, and add a second tag if you publish both a version and
+# a moving "latest".
+
+format: dirigent/v1
+kind: pipeline
+code: docker-build-push
+name: Build an image and push it
+description: Build an image from a context in the work directory and push every tag to the registry a docker connection names.
+
+tags: [docker, execute]
+
+requires:
+  blocks:
+    - docker.run
+    - docker.build
+  workers:
+    # An image built on worker A is invisible to worker B, so both steps have to meet one
+    # docker-capable worker: give those the tag (dg worker --tag docker) and name it here.
+    - docker
+  connections:
+    # Named, not carried: the instance holds the registry credential, and this document
+    # refuses to apply where it is absent rather than failing the first time it runs.
+    - ghcr
+
+params:
+  type: object
+  additionalProperties: false
+  properties:
+    image_tag:
+      type: string
+      default: ghcr.io/your-account/dirigent-greeter:1.0.0
+      description: The fully qualified tag the build gives the image and the push sends.
+
+steps:
+  dockerfile:
+    block: docker.run
+    deadline: 5m
+    config:
+      image: alpine:3
+      pull: true
+      network: none
+      # A target with no URI scheme lands in the run's work directory on this worker, which
+      # is where the build below reads its context from; a URI would send the file to storage.
+      outputs:
+        Dockerfile: "context/Dockerfile"
+      command: |
+        cat > /dirigent/outputs/Dockerfile <<'DOCKERFILE'
+        FROM alpine:3
+        RUN echo "baked in at build time" > /greeting.txt
+        CMD ["cat", "/greeting.txt"]
+        DOCKERFILE
+      memory: 64mb
+      pids_limit: 64
+
+  build:
+    block: docker.build
+    depends_on: [dockerfile]
+    deadline: 15m
+    config:
+      context: context
+      dockerfile: Dockerfile
+      # A pushed tag carries its registry, so this name is where the image ends up as much as
+      # what it is called.
+      tags: ["${params.image_tag}"]
+      pull: true
+      # The connection holds the registry, the username and the sealed password. It could hold
+      # a daemon too: one connection can name both, and the steps that build and the steps that
+      # run would then all name it.
+      connection: ghcr
+      push: true

dirigent_examples/shelves/docker/docker-build-run.yaml

@@ -0,0 +1,106 @@
+# Building an image on the worker, then running it, and why both steps must meet one daemon.
+#
+# REQUIRES A DOCKER DAEMON the worker can reach, named by DOCKER_HOST (a dind sidecar over
+# tcp+TLS, or the local socket in dev). docs/docker.md is the family's home.
+#
+# docker.run and docker.build both declare local_execution, so the engine refuses them unless
+# the instance allowlists their ids:
+#   dg run --local examples/docker/docker-build-run.yaml --enable-unsafe docker.run,docker.build
+#   export DIRIGENT_ENABLED_UNSAFE_BLOCKS='["docker.run","docker.build"]'
+#
+# Three hops, and what each one hands on:
+#   dockerfile  a container writes a Dockerfile into context/ in the run's work directory.
+#               docker.build takes a context DIRECTORY on the worker's filesystem and has no
+#               inline form, so getting the context there is the pipeline's job.
+#   build       buildx builds that directory and loads the result into the worker's own daemon
+#               store. The output carries the image id, its size in bytes, and its tags.
+#   greet       docker.run runs the image by tag with no CMD of its own, so the image's own
+#               CMD is what runs. The output carries its stdout, exit code and container id.
+#
+# THE TAG IS THE CONTRACT. Nothing is pushed here, so the image exists only in the store of the
+# daemon that built it, under the tags the build gave it. That name is all the run step has,
+# which is why both steps read it from one parameter. docker-build-push.yaml is the other half:
+# a docker connection with a registry credential, and an image that leaves the worker.
+#
+# ONE DAEMON, THEREFORE ONE WORKER. An image built on worker A is invisible to worker B, so
+# give the docker-capable workers a `docker` tag (dg worker --tag docker) and declare
+# requires.workers: [docker] below, which is what keeps both steps on one of them.
+#
+# TO MAKE IT YOURS: replace the Dockerfile the first step writes with your own, or drop that
+# step and point the build at a context an upstream storage.copy put in the work directory
+# instead, and give the image a tag of your own.
+
+format: dirigent/v1
+kind: pipeline
+code: docker-build-run
+name: Build an image, then run it
+description: Write a Dockerfile into the run's work directory, build it with buildx, and run the tag.
+
+tags: [docker, execute, starter]
+
+requires:
+  blocks:
+    - docker.run
+    - docker.build
+  workers:
+    - docker
+
+params:
+  type: object
+  additionalProperties: false
+  properties:
+    image_tag:
+      type: string
+      default: dirigent-greeter:local
+      description: The tag the build gives the image, and the only name the run step has for it.
+
+steps:
+  dockerfile:
+    block: docker.run
+    deadline: 5m
+    config:
+      image: alpine:3
+      pull: true
+      network: none
+      # Whatever the container leaves in its output mount is copied where the target names
+      # once it exits. A target with no URI scheme is a path in the run's work directory on
+      # this worker, which is where a build context is read from; a URI would send the file to
+      # storage instead, for a result that outlives the run.
+      outputs:
+        Dockerfile: "context/Dockerfile"
+      command: |
+        cat > /dirigent/outputs/Dockerfile <<'DOCKERFILE'
+        FROM alpine:3
+        RUN echo "baked in at build time" > /greeting.txt
+        CMD ["cat", "/greeting.txt"]
+        DOCKERFILE
+      memory: 64mb
+      pids_limit: 64
+
+  build:
+    block: docker.build
+    depends_on: [dockerfile]
+    deadline: 10m
+    config:
+      # A directory inside the run's work directory, never an absolute path: the same
+      # "context/" the step above wrote into, with the Dockerfile named relative to it.
+      context: context
+      dockerfile: Dockerfile
+      # The image is loaded into the worker's daemon store under this tag, and the id comes
+      # back from buildx's --iidfile rather than scraped out of the build log.
+      tags: ["${params.image_tag}"]
+      # Fetch a newer alpine:3 rather than building on whatever the daemon happens to hold.
+      pull: true
+
+  greet:
+    block: docker.run
+    depends_on: [build]
+    deadline: 5m
+    config:
+      image: "${params.image_tag}"
+      # pull stays off, and must: the image was never pushed, so a pull would go looking for
+      # this tag in a registry and fail with a name the daemon already has locally.
+      pull: false
+      network: none
+      memory: 64mb
+      pids_limit: 64