Automattic / Automattic/wp-codebox

Define resolved workflow specs for canonicalized recipe input paths

Offen
#1,697 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
Vorherrschende Sprache
TypeScript
Sterne
16
Forks
4
Ø Merge
59 Min.
Gemergte PRs (30 T.)
131

Beschreibung

## Summary

WP Codebox currently treats recipe input mount paths as both caller-facing declarations and executable runtime paths. When recipe input mounts are canonicalized/materialized under `/tmp/wp-codebox-inputs/...`, workflow command args can still reach runtime execution with the original declared paths such as `/wp-codebox-vendor` or `/home/wpcom/public_html`.

The immediate symptom is #1696, but the architectural issue is broader: path canonicalization is a late helper rewrite rather than a single authoritative recipe execution boundary.

## Current path identities

- Declared recipe paths: caller-facing paths such as `/wp-codebox-vendor` and `/home/wpcom/public_html`.
- Canonical runtime paths: internal materialized paths such as `/tmp/wp-codebox-inputs/2-wp-codebox-vendor-...`.
- Command argument paths: values embedded in workflow args such as `cwd=`, `autoload-file=`, `tests-dir=`, `test-root=`, `phpunit-xml=`, etc.

These path identities can diverge. We have evidence that `recipeInputMountPathMap()` and `rewriteInputMountPathArgs()` produce the right canonical args, while `wordpress.phpunit` runtime execution still receives the original declared path.

## Desired model

Recipe execution should have a first-class resolved workflow spec phase:

1. Runtime setup prepares input mounts and returns a path resolution context.
2. Workflow steps are converted to resolved execution specs exactly once before `runtime.execute()`.
3. Runtime commands receive resolved runtime paths only.
4. Declared paths remain available as evidence/metadata, not executable args.
5. Diagnostics expose original args and resolved args.
6. If an executable arg still references a canonicalized declared mount target, recipe-run should fail loud before runtime execution.

## Acceptance criteria

- All recipe workflow command execution paths pass through one resolver before runtime execution.
- Nested workload/fuzz workflow execution uses the same resolver.
- `wordpress.phpunit` with input mounts for `/wp-codebox-vendor` and `/home/wpcom/public_html` receives canonical `/tmp/wp-codebox-inputs/...` args.
- Evidence records both original and resolved args for debugging.
- A guard catches unresolved canonicalized mount targets in executable args.
- Fix remains generic: no Homeboy or WPCOM-specific logic.

## Related

- Immediate bug: #1696
- WPCOM blocker run: `runner-exec-test-wpcom-homeboy-lab-e66e6a80-e042-4727-aa17-75b3a17ccf31`

## AI assistance

- **AI assistance:** Yes
- **Tool(s):** openai/gpt-5.5 via OpenCode
- **Used for:** Diagnosing the path model failure and drafting this architectural issue.

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Rechercherichtung

Verfolge recipeInputMountPathMap(), rewriteInputMountPathArgs() und die Workflow-Pfade, die runtime.execute() aufrufen; vergleiche die Ausführung gewöhnlicher und verschachtelter Workloads/Fuzz-Ausführung, einschließlich wordpress.phpunit. Definiere die Grenze der aufgelösten Workflow-Spezifikation, damit Laufzeitbefehle kanonische Pfade erhalten, während die Evidenz ursprüngliche und aufgelöste Argumente beibehält und recipe-run nicht aufgelöste Mount-Ziele ablehnt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
typescript
Bereich
backend
Issue-Typ
Refactoring
Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Aktivitätsstatus
Ruhig
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
38/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.