Reject unsupported Windows shells before workflow jobs start

[dannymidnight]

Why

A statically known unsupported shell currently reaches runtime before failing, after an agent claims the generated workflow job:

- shell: pwsh
  run: Write-Output test

This delays actionable compatibility feedback.

Closes PB-3021

This covers only the unsupported-shell slice of PB-2951.

What

Statically resolved shell and defaults.run.shell values now reject PowerShell and Windows shell commands during workflow processing. The diagnostic names the shell, attributes its source, job, and step, and points to supported alternatives.

Runtime-dependent shell expressions stay in job plans and retain fail-closed runtime validation. Valid custom templates such as bash -l {0}, Rscript {0}, and julia --color=yes {0} continue to compile when their commands are available on PATH.

Preview

Step shell

Workflow could not be run

.github/workflows/shells.yml

shell "/opt/microsoft/powershell/7/pwsh -File {0}" is unsupported.

.github/workflows/shells.yml:6:9 · Job test · Step 1

PowerShell and Windows shells cannot run in buildkite-gha.

Use bash, sh, python, or a valid custom shell template whose command is available on PATH, or file a compatibility issue at https://github.com/buildkite/buildkite-gha

---

Job default shell

Workflow could not be run

.github/workflows/shells.yml

shell "cmd" is unsupported.

.github/workflows/shells.yml:3:3 · Job test

PowerShell and Windows shells cannot run in buildkite-gha.

Use bash, sh, python, or a valid custom shell template whose command is available on PATH, or file a compatibility issue at https://github.com/buildkite/buildkite-gha

[buildsworth-bk-app]

One report-boundary issue blocks this revision: the new preflight can publish event-derived shell text. Details are inline.

Want to dig deeper?

Paste this into your agent to explore the findings from this review's Buildkite build:

Download the buildsworth logs from build 20233, then answer my questions about the findings.

Install the reading-buildsworth-logs skill to run this.

About buildsworth

Model: gpt-5.6-sol with xhigh thinking.

How to request a review: Comment @buildsworth-bk review on the PR, or request buildsworth-bk as a reviewer.

Risk labels (how buildsworth classifies risk) — buildsworth classifies risk itself from the diff. Unless repository policy already allows L2 approval, grant it by mentioning @buildsworth-bk (see approval ceiling and L2 approval grant):

• L1 — Low risk (dep bumps, docs/copy, lockfiles, small presentational fixes). buildsworth may approve by default.
• L2 — Standard risk (new UI, additive API fields, refactors). Approved only when repository policy or a verified grant allows it; otherwise comment-only.
• L3 — High risk (auth, migrations, payments, secrets, perf-critical paths). Human review always required.

[buildsworth-bk-app]

Blocking: Message includes the fully resolved shell, but reducePlanEventExpressions has already folded event values into site.Source before this runs. For example, shell: pwsh -File {0} ${{ github.event.pull_request.title }} lets PR-controlled title text reach the generated failure report. That violates the ProcessingFinding.Message invariant in processing.go that report messages must not contain event-derived data. Please report only fixed guidance or the normalized blocked command here, or include the exact shell only when its provenance is known to be workflow-authored.