dispatch-workflow / call-workflow: findWorkflowFile never checks the .yaml extension

[blozano-tt]

Summary

dispatch-workflow’s same-repo workflow resolution (findWorkflowFile in pkg/workflow/dispatch_workflow_file_resolver.go) only builds candidate paths for .md, .lock.yml, and .yml. It never checks .yaml, so a plain, hand-written GitHub Actions workflow using the (equally valid, very common) .yaml extension can never be referenced as a dispatch-workflow target by its bare name — compilation fails with “workflow not found” even though the file exists and has a workflow_dispatch trigger.

Reproduction

Repo layout:

.github/workflows/target.yaml # plain GH Actions workflow, has on: workflow_dispatch:
.github/workflows/caller.md # gh-aw workflow
caller.md frontmatter:

safe-outputs:
dispatch-workflow:
workflows: [target]
Run:

gh aw compile

Expected

Compilation succeeds; target.yaml is resolved and validated the same way target.yml would be.

Actual

dispatch-workflow: workflow 'target' not found in .github/workflows

Checked for: target.md, target.lock.yml, target.yml

To fix:

1. Verify the workflow file exists in .github/workflows/
2. Ensure the filename matches exactly (case-sensitive)
3. Use the filename without extension in your configuration
   Note the checked list omits .yml’s equally-valid sibling extension, .yaml.

Root cause

In findWorkflowFile (same file):

mdPath := filepath.Clean(filepath.Join(searchDir, workflowName+".md"))
lockPath := filepath.Clean(filepath.Join(searchDir, workflowName+".lock.yml"))
ymlPath := filepath.Clean(filepath.Join(searchDir, workflowName+".yml"))
No .yaml candidate is ever constructed. The “not found” error text in pkg/workflow/dispatch_workflow_validation.go:65 mirrors the same three-extension list, so the message is internally consistent — it’s just missing a fourth branch.

I traced this while wiring up a dispatch-workflow target against a real-world repo (tenstorrent/tt-metal) where every hand-written CI workflow uses .yaml (not .yml) by convention — this isn’t a hypothetical edge case, it blocks the feature entirely for any repo that standardized on the .yaml spelling.

Suggested fix

Add a fourth candidate, .yaml, alongside the existing .yml check in findWorkflowFile (and the corresponding existence flag / error message), mirroring how GitHub Actions itself treats .yml/.yaml as interchangeable for workflow files. call-workflow (pkg/workflow/call_workflow_validation.go) calls this exact same findWorkflowFile function, so it has the identical gap — fixing findWorkflowFile fixes both call sites at once.

Environment

gh-aw version: v0.84.0 (also confirmed present on main @ 6d65f8a as of 2026-07-30)

[blozano-tt]

According to yaml.org, the official file extension is .yaml.

[blozano-tt]

I have a complete, tested fix for this on a branch, but I can't open the PR — blozano-tt has read-only access to this repo, so createPullRequest is rejected (which matches CONTRIBUTING.md: traditional PRs from non-core-team members aren't enabled). Leaving the details here so a core-team member can pick it up or open the PR from the branch directly.

Branch: https://github.com/blozano-tt/gh-aw/tree/fix/dispatch-workflow-yaml-extension
Compare/PR link: main...blozano-tt:gh-aw:fix/dispatch-workflow-yaml-extension

Fix

Add a fourth <name>.yaml candidate in findWorkflowFile. Since GitHub Actions treats .yml and .yaml as equivalent, the two share one priority tier between .lock.yml and .md rather than each getting their own; .yml wins only if both files somehow exist. This mirrors the existing convention in isYAMLWorkflowFile (pkg/parser/yaml_import.go) and the []string{"action.yml", "action.yaml"} probes in pkg/workflow/safe_outputs_actions.go.

findWorkflowFileResult turned out to have nine consumers, so rather than repeat a fourth branch nine times I added two small helpers on it:

• anyExists() — replaces the mdExists || lockExists || ymlExists existence checks.
• plainYAMLWorkflow() (path, extension string, found bool) — returns the hand-written workflow's path and extension.

Returning the extension matters beyond validation. resolveWorkflowExtension feeds SafeOutputs.DispatchWorkflow.WorkflowFiles, and actions/setup/js/dispatch_workflow.cjs builds the dispatch target as `${workflowName}${extension}`. Recording .yml for a .yaml target would compile cleanly and then 404 at dispatch time — so every consumer that picks a file to read or reference needed the .yaml case, not just the "not found" path. No JS changes were needed; the handler is extension-agnostic.

Files touched: dispatch_workflow_file_resolver.go, dispatch_workflow_validation.go, call_workflow_validation.go, safe_outputs_workflow_helpers.go, safe_outputs_dispatch.go, safe_outputs_call_workflow.go, safe_outputs_tools_generation.go, call_workflow_permissions.go, call_workflow_secrets.go, compiler_safe_output_jobs.go, plus the validation-rules list in docs/src/content/docs/reference/safe-outputs.md and the two "Checked for: …" error strings.

Tests added

• TestFindWorkflowFileYAMLExtension — resolver detects the .yaml candidate.
• TestDispatchWorkflowFileExtensionResolution — extended with a yaml-test.yaml sibling next to the existing .lock.yml/.yml cases.
• TestDispatchWorkflowYAMLExtensionValidation — a .yaml target validates and maps to .yaml.
• TestDispatchWorkflowNotFoundListsYAMLExtension — the error advertises every extension actually checked.
• TestValidateCallWorkflow_YAMLExtension — a .yaml worker validates and is referenced as ./.github/workflows/worker-a.yaml.
• TestResolveWorkflowExtension — added .yaml, .yml-beats-.yaml, .lock.yml-beats-.yaml cases.

Verification

go build ./..., go vet ./pkg/workflow/... and go test ./pkg/workflow/... all pass. go test ./... passes except one pre-existing, unrelated failure that also fails on unmodified main in my sandbox: TestInstallCopilotCLIScriptResolvesCompatVersionBeforeToolcacheLookup (pkg/cli), which fetches an unmocked copilot-cli/releases/download/v1.0.75/SHA256SUMS.txt.

End-to-end with the exact repro from the description: unmodified main fails with the reported Checked for: target.md, target.lock.yml, target.yml error; with the fix it compiles and embeds "workflow_files":{"target":".yaml"} in the lock file.

[blozano-tt]

If it is not clear in the issue.

The original goal I had was having the agentic workflow dispatch our repo's existing hand crafted workflows, for things like compiling the project, or launching a test run. Something that I would not want to backport into natural language - and pray that the compiler outputs the right thing.