Skip to content

Run all samples on a Windows runner from Git Bash - #48

Merged
paolosalvatori merged 12 commits into
mainfrom
windows-git-bash-samples-ci
Oct 26, 2026
Merged

paolosalvatori merged 12 commits into
mainfrom
windows-git-bash-samples-ci

Conversation

@paolosalvatori

@paolosalvatori paolosalvatori commented Oct 23, 2026 •

Copy link
Copy Markdown
Collaborator

Motivation

#47 asks Windows users of Git Bash and MSYS2 to export MSYS_NO_PATHCONV=1 and adapts the scripts to it, but the samples workflow runs only on Linux, so nothing checks that the scripts work from Git Bash.
This adds a Windows job that runs every app there end to end, on demand, as a reproduction of that setup.
It is stacked on #47 and will be retargeted to main once that pull request merges.

Fixes SMF-981

Changes

  • A new platform input of the manual run, a dropdown with Windows, Linux (the default) and all, chooses where the selected apps run, and run_mode selects the apps on both platforms. The setup job puts one entry per app and platform in the matrix, each naming its runner and its job, and the one sample job runs them, its Windows-only and Linux-only steps gated on the entry's platform: a run lists only the jobs it runs, Windows (Git Bash) <sample> (<language>) on Windows, and the Linux jobs keep their names.
  • A Windows job runs on windows-latest and uses Git Bash, the default bash shell of Windows runners, with MSYS_NO_PATHCONV=1 set as the README asks. For each app it creates the AKS cluster with scripts/01-system-assigned-managed-identity.sh, deploys the app with its numbered scripts and checks it with tests/test-vacation-planner.sh, as the Linux job does, with the same answers to the Azure Files sample's menus and the same cluster state on failure.
  • The emulator is a Linux image, and Docker on the Windows runner runs Windows containers, so the job starts Docker Engine inside an Ubuntu WSL 2 distribution (Vampire/setup-wsl) and runs the emulator there with docker run. The Windows docker CLI, lstk and kubectl reach it through ports WSL forwards to the runner's localhost. Installing docker.io already starts a daemon on the Unix socket alone, so the job stops it and starts one that also listens on TCP, and waits on the TCP endpoint.
  • As the README asks, bash drops the carriage returns Windows programs print (set -o igncr), turned on for every bash through BASH_ENV, since exporting SHELLOPTS in a step would hand the step's own -e and pipefail to the sample scripts.
  • WSL's DNS tunneling is turned off: with it, the containers of the Docker Engine in WSL could not reach WSL's resolver, and the Container Apps runtime could not pull images; without it, WSL hands out the NAT device on the host as the DNS server, which containers reach too.
  • lstk 1.4.0 cannot register its Azure CLI cloud on Windows when the CLI sits under C:\Program Files: it passes the cloud configuration's JSON to az.cmd, and cmd.exe cuts that command line at the space ('C:\Program' is not recognized). A junction without spaces, first on the PATH, works around it until lstk passes the JSON another way.
  • yq, which the Windows runner image lacks, comes from a pinned release checked against its SHA-256, and the Azure SQL Database app gets the Go sqlcmd release, pinned the same way. psql, which the image installs off the PATH, goes on it for the PostgreSQL and App Configuration apps.

Tests

  • actionlint with shellcheck on the workflow and on each bash step, and the repository's pre-commit hooks (zizmor, gitleaks).
  • The first manual runs stopped before any app ran and found two Windows problems, now fixed: the Docker daemon the package started and the lstk cloud registration above.
  • The first full run reached every app's deployment and found two more problems: psql off the PATH (fixed here) and curl's -o /dev/null, which stopped the end-to-end test with exit code 23 (fixed in Run the scripts from Git Bash and MSYS2 on Windows #47).
  • This manual run runs every app with all of them fixed.

Related

🤖 Generated with Claude Code

https://claude.ai/code/session_01DhZ2ojsEXd2SGMo7s9uiZh

A manual run with the new windows input, instead of the Linux matrix, creates the AKS cluster, then deploys and tests the Cosmos DB and Blob Storage samples on windows-latest from Git Bash, with MSYS_NO_PATHCONV=1 set as the README asks Windows users to do.
The emulator is a Linux image and Docker on the Windows runner runs Windows containers, so the job runs it in Docker Engine inside an Ubuntu WSL 2 distribution, which the Windows docker CLI, lstk and kubectl reach over ports WSL forwards to localhost.
yq, which the runner image lacks, comes from a pinned release checked against its SHA-256.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhZ2ojsEXd2SGMo7s9uiZh
paolosalvatori and others added 3 commits October 23, 2026 16:32
…ged one

Installing docker.io in the WSL distribution already starts a Docker daemon on the Unix socket alone, so the daemon the job started with TCP port 2375 exited at once ("process with PID 1063 is still running"), the readiness check passed against the packaged daemon, and the Windows docker CLI found nothing on the port.
The step now stops the packaged daemon (its systemd units, or its PID file without systemd), starts its own, and waits on the TCP endpoint.
The Docker Engine log step runs only once WSL is set up, since its wsl-bash shell does not exist before that.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhZ2ojsEXd2SGMo7s9uiZh
The Windows job takes its matrix from the setup job, which on a manual run with the windows input selects every app, and the Linux matrix stays out of that run.
It now provides what the remaining apps need, as the Linux job does: sqlcmd for the Azure SQL Database sample (the Go sqlcmd release, pinned with its SHA-256) and the answers to the Azure Files sample's provisioning menus; on failure it prints the same cluster state.
lstk 1.4.0 cannot register its Azure CLI cloud on Windows when the CLI sits under C:\Program Files: cmd.exe cuts the command line that carries the cloud configuration's JSON at that space. A junction without spaces, first on the PATH, works around it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhZ2ojsEXd2SGMo7s9uiZh
@paolosalvatori
paolosalvatori requested a balanced review from Copilot October 23, 2026 15:00
@paolosalvatori paolosalvatori changed the title Run two samples on a Windows runner from Git Bash Run every sample on a Windows runner from Git Bash Oct 23, 2026

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

Missing PostgreSQL client setup and incompatible curl output handling prevent the Windows matrix from completing its intended checks.

2 open issues
What changed in this PR

Adds on-demand Windows coverage for the AKS samples, exercising deployment and end-to-end checks from Git Bash alongside the existing Linux workflow.

Changes:

  • Adds a manual windows input that selects every sample and skips the Linux matrix.
  • Runs the emulator through Docker Engine in WSL 2, with Windows-side tooling and an Azure CLI path workaround.
  • Reuses cluster creation, sample deployment, tests, and failure diagnostics on Windows.
File Description
.github/​workflows/​samples.yml Adds Windows job selection, environment setup, and sample validation.

Review effort: Balanced

Comment thread .github/workflows/samples.yml
Comment thread .github/workflows/samples.yml
paolosalvatori and others added 4 commits October 23, 2026 17:20
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhZ2ojsEXd2SGMo7s9uiZh
The PostgreSQL and App Configuration samples seed their databases with psql; the Windows runner image installs PostgreSQL with psql off the PATH, where the Linux runner image has the client on it, so five apps stopped with "psql is not installed on the host".

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhZ2ojsEXd2SGMo7s9uiZh
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhZ2ojsEXd2SGMo7s9uiZh
…the README asks

The README asks Windows users for set -o igncr and export SHELLOPTS. Exporting SHELLOPTS in a step would also hand the step's own -e and pipefail to the sample scripts, so the job turns the option on for every bash through BASH_ENV instead.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhZ2ojsEXd2SGMo7s9uiZh
@paolosalvatori paolosalvatori changed the title Run every sample on a Windows runner from Git Bash Run all samples on a Windows runner from Git Bash Oct 23, 2026
paolosalvatori and others added 2 commits October 23, 2026 18:45
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhZ2ojsEXd2SGMo7s9uiZh
With DNS tunneling, on by default, the containers of the Docker Engine in WSL could not reach the 10.255.255.254 resolver WSL configures, so their lookups timed out: the Docker Engine log held dozens of "failed to query external DNS server" errors, and the Container Apps runtime could not pull the sample's image (ImagePullBackOff). Without tunneling, WSL hands out the NAT device on the host as the DNS server, which containers reach too (https://learn.microsoft.com/windows/wsl/troubleshooting#common-issues).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhZ2ojsEXd2SGMo7s9uiZh
@paolosalvatori
paolosalvatori marked this pull request as ready for review October 26, 2026 09:16
@paolosalvatori
paolosalvatori changed the base branch from smf-963-web-app-cosmosdb-nosql-api-sample-fails-on-windows-git-bash to main October 26, 2026 09:17
paolosalvatori and others added 2 commits October 26, 2026 14:17
… windows checkbox

A manual run now picks where the selected apps run with the platform input: Linux (the default),
Windows, or all, which runs the Linux and Windows jobs side by side in the same run. run_mode
selects the apps on both platforms, so a Windows run follows it too instead of always running
every app.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhZ2ojsEXd2SGMo7s9uiZh
GitHub lists a matrix job it skips under its unexpanded name, so a pull request run showed
"Windows (Git Bash) ${{ matrix.sample }} (${{ matrix.language }})" and a Windows run the Linux
equivalent. The setup job now puts one entry per app and platform in a single matrix, each naming
its runner and its job, and one job runs them all, its Windows-only and Linux-only steps gated on
the entry's platform. A run lists only the jobs it runs, and the Linux jobs keep their names.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhZ2ojsEXd2SGMo7s9uiZh
@paolosalvatori
paolosalvatori merged commit 6addb8a into main Oct 26, 2026
103 of 105 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants