Workflows compiled with gh aw compile emit {{#runtime-import ...}} macros that resolve files from the checked-out workspace at runtime. This breaks workflow_call usage because the consumer repo's workspace doesn't contain the fragment files -- they only exist in the central repo.
Error: Failed to process runtime import for .github/workflows/gh-aw-fragments/elastic-tools.md:
Runtime import file not found: workflows/gh-aw-fragments/elastic-tools.md
Proposed solution:
Expose the existing inlinePrompt compiler option as a user-facing setting (frontmatter field and/or CLI flag). When enabled, the compiler embeds all markdown content -- both imported fragments and the main workflow body -- directly into the .lock.yml instead of emitting runtime-import macros.
The compiler already supports inlining for Wasm/browser builds (WithInlinePrompt), but today it only inlines the main workflow body. Imported fragments without inputs always emit runtime-import macros regardless of the flag. Both need to honor the setting.
Workflows compiled with
gh aw compileemit{{#runtime-import ...}}macros that resolve files from the checked-out workspace at runtime. This breaksworkflow_callusage because the consumer repo's workspace doesn't contain the fragment files -- they only exist in the central repo.Proposed solution:
Expose the existing inlinePrompt compiler option as a user-facing setting (frontmatter field and/or CLI flag). When enabled, the compiler embeds all markdown content -- both imported fragments and the main workflow body -- directly into the .lock.yml instead of emitting runtime-import macros.
The compiler already supports inlining for Wasm/browser builds (WithInlinePrompt), but today it only inlines the main workflow body. Imported fragments without inputs always emit runtime-import macros regardless of the flag. Both need to honor the setting.