ci: run tasks with the flow binary under review

[jahvon]

Important

Depends on flowexec/action#2. Until that lands and v1 moves, the flow-binary input is ignored and these jobs behave exactly as they do today (see Merge order below).

Summary

Every CI job installed flow via flowexec/action with flow-version: main, which clones flow from GitHub and builds main — discarding the branch under review. CI validated each change with a flow that predated it.

Each job now builds flow first and passes it through:

- name: Build flow
  run: go build -o ./bin/flow .
- uses: flowexec/action@v1
  with:
    executable: 'test unit'
    flow-binary: ./bin/flow

Why it matters

For the Go-test jobs the gap is mostly benign — flow is only the task runner, and go test compiles the PR's code either way. It stops being benign as soon as a .execs target depends on a flow capability that has not shipped.

That is not hypothetical. #439 adds Python execution, and its .execs target failed on every platform:

Executing: flow test python-script
unable to parse file - 14:1: `foo(` must be followed by `)`

The released flow parsed the .py file as shell. No change to that PR could have made the job pass — the capability has to be on main before CI can use it, which is circular. The job there was reworked to build locally; this PR generalizes that to every job rather than leaving it a one-off.

Merge order

flow-version: 'main' is deliberately kept alongside flow-binary, so this is safe to merge in either order:

Action version	Behavior
With flowexec/action#2	flow-binary wins → tasks run the PR's build ✅
Without it	Input ignored, falls back to flow-version: main → today's behavior, CI stays green

Without that fallback the input would be silently dropped and flow-version would default to latest, quietly changing which flow runs. The flow-version lines can be removed once v1 carries the input.

Notable Changes

• ci.yaml: lint, unit-tests, e2e-tests, validate-generated, build-matrix, security.
• windows-ci.yml: unit-tests, e2e-tests, binary-smoke, native-scripts.
• build-matrix names the binary per-OS (flow.exe on Windows) rather than relying on whether go build -o appends the extension. Its bootstrap lives in ./bin; build binary still writes its own to .bin, so they do not collide.

Deliberate exclusions

• windows-ci's build-binary job keeps flow-version: latest — its whole purpose is to exercise the install script.
• release, container, release-docs are untouched. The same reasoning applies (arguably more so: a tag build should use the tagged code), but they publish artifacts and cannot be verified from a pull request. Worth a follow-up.

Testing

Both workflow files parse as valid YAML. The end-to-end proof is this PR's own CI run once flowexec/action#2 is released — the step log should read Using provided flow binary: ./bin/flow instead of Building flow from main branch....

Note this touches the same jobs as #439, which adds setup-python and a python-scripts job. Whichever merges second needs a rebase; the changes are complementary, not conflicting in intent.

🤖 Generated with Claude Code

https://claude.ai/code/session_01R328pa3FUUfga4gYah1iQi

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[jahvon]

v1 now points at v1.3.0, which carries the flow-binary input. Re-running CI to confirm the jobs pick up the locally built binary.