feat(hm): pipelines + render commands (machine-readable IR for backend discovery)#33
Merged
Merged
Conversation
b50a3fe to
0a186db
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Two stdout-only subcommands so the Harmont backend can produce pipeline IR by shelling out to
hm— noimport harmont/ pip needed in the render sandbox:hm pipelines [--dir DIR]— prints the full discovery envelope JSON(
{"schema_version":"1","pipelines":[{slug,name,allow_manual,triggers,definition}]})via
harmont.dump_registry_json().hm render <slug> [--dir DIR]— prints that one pipeline's v0 IR JSON(
{"version":"0","graph":{...}}).Both write only the raw JSON to stdout; all diagnostics go to stderr; nonzero exit on failure.
Why
The backend's Runloop render sandbox has no
harmontPython package, so the oldpython3 -c 'import harmont'discovery path fails withModuleNotFoundError.hmalready embeds the DSL engine; these commands expose what it already computes (dump_registry_json/render_pipeline_json). The backend will shell out to them (separate change).How
DslEngine::registry_jsonreturns the envelope verbatim. Python engine: a new script thatsys.stdout.write(hm.dump_registry_json()). TS engine bails explicitly — Python only for now (hm renderstill works for TS; only the registry dump is deferred).cli/pipelines.rs,cli/render.rs) mirroringcli/run.rs/version.rs; wired into theCommandenum + dispatch.Tests
hm-dsl-engine/tests/python_engine_test.rs— envelope carries triggers + allow_manual + a v0definition.hm/tests/cmd_pipelines.rs,hm/tests/cmd_render.rs— CLI smoke tests (stdout JSON shape; unknown-slug fails with available slugs on stderr). All self-skip whenpython3is absent.cargo clippy --all-targets -- -D warningsis clean; all new tests pass.Notes for reviewers
hm pipelinesstdout feeds discovery (reads slug/name/allow_manual/triggers; ignoresdefinition).hm render <slug>stdout is one slug's v0 IR..harmont/has bothci.pyandci.ts, so language detection picks TypeScript there —hm pipelinestherefore bails with the Python-only message on this repo (by design).hm render ciworks.cmd_plugin::plugin_list_shows_registered_runnersfails identically onmain(asserts stdout while the runner list goes to stderr). Not touched by this PR.