Review summary

Change reviewed

PR #384 updates reusable-workflow failures so annotations explain supported next steps. It:

• expands the compound needs input error with the exact whole-value string form;
• turns remote secret-forwarding failures into structured ProcessingFinding diagnostics that identify the called workflow;
• gives private repositories and missing public workflow files the same non-enumerating diagnostic;
• replaces the “runtime-dependent” workflow-path error with literal local and public examples;
• adds compiler and upload tests for messages, source attribution, and rendered annotations.

The change addresses PB-3041, PB-3026, PB-3016, and PB-3017. I read those Linear issues and compared their requested guidance with the implementation.

Evidence examined

I read the complete PR diff and all five changed files. I traced:

• both loadReusableWorkflow call sites, including runtime-matrix discovery and normal reusable-workflow resolution;
• resolveCallSecretAuthority and requiredSecrets, which determine whether called jobs receive Buildkite secret authority;
• ProcessingFinding attribution and compatibility-report rendering;
• existing reusable-workflow secret tests and the supported boundaries in docs/compatibility.md;
• the new tests for dynamic paths, unavailable public workflows, remote forwarding, and compound needs values.

The structured error propagation preserves source path, line, column, and job attribution. The shared unavailable-workflow helper also keeps missing and private references deliberately indistinguishable. Existing tests continue to cover local secrets: inherit and explicit mappings.

GitHub reported the main Buildkite build and its public-actions and shell-smoke jobs as passed for commit 40a450e4e535a20ff62e8a949862f9a6ed96738d; Socket checks also passed. I could not query those Buildkite builds through bk because the available API token could not access the organization. I also could not run Go tests, vet, or gofmt locally because neither the pinned mise installation nor Go was available in this environment.

Finding and verdict

I requested changes with one blocking inline finding in internal/compiler/reusable.go.

Both new remote-secret diagnostics advise users to “reference each secret by name in the jobs of that workflow.” However, removing forwarding leaves the called workflow with an empty restricted secretAuthority. requiredSecrets then drops direct ${{ secrets.NAME }} references, as also demonstrated by TestCompileDoesNotGrantUninheritedReusableWorkflowSecrets. Following the new guidance therefore leaves the remote job without the secret and produces an empty runtime value.

The smallest correction is to remove that unsupported alternative, or explicitly name buildkite-agent secret get NAME if direct agent retrieval is the intended remote-job mechanism. The repository-local copy plus secrets: inherit or an explicit map remains a valid alternative.

Trigger source: automatic.