cristhian
7d9ebe8b38
It is a test fixture, so it lives in tests/. It was only ever an example by placement: CI runs it as the end-to-end gate, SOURCE_FRAMES exists so CI can bound it, and it publishes depth and camera_info because those inputs are typed and strict validation fails on a typed input the dataflow does not wire -- none of which is pedagogy. The worked example of wiring this node is the README's usage block, against a real camera. It stays a dora node rather than a pytest case because what it exercises is the wiring and the event loop, which only a running dataflow covers. pytest does not collect it: the filename does not start with `test_`. dataflow.yml stays at the repository root rather than moving beside it. A node's working directory is the directory of the dataflow file, and both nodes build with `pip install .`, which needs pyproject.toml in that directory.
62 lines
2.4 KiB
YAML
62 lines
2.4 KiB
YAML
# The end-to-end test: a synthetic source feeding the viewer. Everything it
|
|
# needs is in this checkout -- no camera, no detector, no network -- which is
|
|
# what lets CI run it rather than only validate it.
|
|
#
|
|
# It lives at the repository root rather than beside tests/source.py because a
|
|
# node's working directory is the directory of the dataflow file, and both
|
|
# nodes build with `pip install .`, which needs pyproject.toml in that
|
|
# directory.
|
|
#
|
|
# Both nodes are built from the checkout with `path:` + `build:`, which is what
|
|
# lets `dora validate` pick up the typed contract in dora-node.yml. A consumer
|
|
# wires the viewer from a tag instead -- see README.md.
|
|
#
|
|
# Run it with `--uv` so every node gets its own managed environment.
|
|
strict_types: true
|
|
|
|
nodes:
|
|
- id: source
|
|
# Run through the interpreter rather than as `path: tests/source.py`.
|
|
#
|
|
# A dora-node.yml describes exactly one node and is what gets published
|
|
# (`dora hub publish` expects it beside pyproject.toml), and this
|
|
# repository ships one node: dora-image-view. The example source is a test
|
|
# fixture, not a node anyone installs, so it gets no manifest.
|
|
#
|
|
# That has a mechanical consequence. `dora validate` matches a manifest to
|
|
# a `path:` node by entrypoint, so a path node here would be tried against
|
|
# the root manifest, would not match its `dora-image-view` entrypoint, and
|
|
# would warn -- which strict_types turns into a failure. Going through the
|
|
# interpreter leaves nothing for it to match, and `output_types` below is
|
|
# the documented way to type an output without one.
|
|
path: python
|
|
args: tests/source.py
|
|
# The source needs dora-rs, numpy and pyarrow; installing the project gives
|
|
# it exactly the versions pinned in uv.lock.
|
|
build: pip install .
|
|
inputs:
|
|
tick: dora/timer/millis/33
|
|
outputs:
|
|
- image
|
|
- depth
|
|
- camera_info
|
|
- bbox
|
|
- text
|
|
# bbox is deliberately absent: it is untyped on the viewer's side too,
|
|
# because senders disagree on 32- vs 64-bit numeric fields.
|
|
output_types:
|
|
image: std/media/v1/Image
|
|
text: std/core/v1/String
|
|
depth: std/media/v1/Image
|
|
camera_info: std/core/v1/Float32
|
|
|
|
- id: view
|
|
path: dora-image-view
|
|
build: pip install .
|
|
inputs:
|
|
image: source/image
|
|
depth: source/depth
|
|
camera_info: source/camera_info
|
|
bbox: source/bbox
|
|
text: source/text
|