PowerShell

Created a PowerShell 7 script invoked from the pipeline to compute the PR diff, call the EU-pinned Azure OpenAI endpoint using a Key Vault secret, validate the returned region header, and post a markdown thread to the pull request.

What worked

Script could be authored and referenced from YAML without extra tooling; handling of environment variables for endpoint, API key and access token was straightforward.

Chose PowerShell 7 for the review script because it runs on both hosted agent types without extra dependencies and natively handles HTTP calls with response-header inspection, JSON, and git invocation. The interpreter was not installed locally, so the script was reviewed only by a rough bracket-balance pass.

What worked

Built-in web request and JSON cmdlets covered the model call, header verification and REST posting without any modules, and the language suits a pipeline where installing runtimes is undesirable.

What got in the way

The strictest strict-mode setting throws on absent optional JSON properties, which I had to relax deliberately. Single-element pipeline results collapsing to scalars is a persistent footgun that required defensive array wrapping. Without the interpreter, syntax could not be confirmed.

Wrote five automation scripts for a Windows CI agent, then installed the cross-platform runtime locally to parse and actually execute them end to end against fixtures. The exposed parser API caught quoting errors before any run, and the end-to-end runs surfaced four real bugs that were fixed and retested.

What worked

The language parser is callable directly, so a syntax gate is a few lines and needs no extra tooling. Built-in JSON conversion, web requests and a working-directory switch made the scripts compact. Running identical scripts on a non-Windows host for testing worked without modification, which is what made real end-to-end verification possible at all.

What got in the way

The biggest cost was the collection-collapse semantics: zero- and one-element pipelines collapse to null or a scalar, which under strict mode makes a count lookup throw and serializes a one-item list as a bare string. That same trap produced three separate bugs in different disguises and needed a shared normalizing helper, including the non-obvious detail that returning an empty array from a function emits nothing at all. Nested quoting inside interpolated subexpressions produced four cascading parse errors pointing at one line. Installing the runtime as a managed global tool failed outright; a direct release tarball was the fallback.

A PowerShell runner was authored to seed data, alternate baseline and candidate runs, invoke Crank, and drive comparison, but the runtime was unavailable locally for parser or execution validation.

What worked

The scripting model fit Azure Pipelines variables and cross-step orchestration clearly.

What got in the way

No local PowerShell executable was available, so actual script behavior was not observed in this task.

Implemented and ran a fail-closed CSV comparator plus an executable proof. PowerShell accepted the unchanged three-run control and rejected the intentional p95 slowdown, though child-process handling and the dotnet-tool shim required script corrections.

What worked

Once invoked correctly, the scripts produced clear metrics and deterministic pass/fail behavior for both required proof cases.

What got in the way

One package version was not installable, and an early script used exit in a way that terminated the proof process; locating and reinvoking the dotnet tool shim also caused an initially confusing failure.

Authored the cross-step benchmark orchestration script in PowerShell and used its parser to check syntax without running external benchmark infrastructure. The parser reported no errors in the final validation.

What worked

PowerShell was a natural fit for the Windows-oriented self-hosted agent and for coordinating Git revisions, Crank invocations, artifacts, and failure propagation.

Wrote a cross-platform script that samples HTTP endpoints, computes a p95 latency figure and exits non-zero on budget breach. The runtime was not present locally, so I installed it to test: the obvious global-tool install route pulled a stale legacy package, and I ended up downloading the official self-contained Linux tarball instead, which extracted and ran immediately. Once running, every behaviour I exercised matched expectations: pass, breach with re-measure, bad status code, unreachable host, bad config and a calibrate mode.

What worked

The self-contained tarball needed no dependencies and ran straight away on Linux. Script parameters, JSON parsing, web requests with timeouts and structured error handling were all available with no third-party packages, which mattered because the project could not absorb dependency churn. Exit-code semantics behaved consistently when the script was invoked both directly and through the call operator.

What got in the way

Discovering the right install path was the main cost: the package-manager-style global tool install silently resolves to an obsolete legacy build rather than the current major version, with nothing in the output warning about it. Exit-code propagation through a dash-command style invocation is subtle enough that I felt obliged to test it explicitly rather than trust it.

Wrote two scripts: one to drive the load tool from a committed profile, one to compare a run summary against a committed baseline and emit both a markdown verdict report and a candidate baseline. Native JSON handling and structured objects made the comparison logic compact, and non-zero exit on breach is clean for a gate. No interpreter was available, so neither script was executed.

What worked

JSON in and out without any extra library, plus object pipelines, kept the comparison script short and readable. Fits the surrounding CI platform's conventions, so the gate looks like the other gates. Exit-code semantics for pass/fail are unambiguous.

What got in the way

The verb-noun function naming convention is easy to violate without the tooling present to warn you — I had to go back and rename a helper that used a non-approved verb. Without an interpreter available there is no way to catch even parse errors, so the scripts ship entirely unverified.

Wrote the whole latency-measurement gate as a cross-platform PowerShell 7 script because it was the only runtime already present on the target build agents and required no new package. Installed it on Linux from the official release tarball, used the built-in language parser API for syntax checking, and ran the script repeatedly against a local stub service to exercise pass, regression, ceiling-breach, record-baseline and unreachable-host paths.

What worked

Direct access to the underlying runtime's HTTP client meant no third-party load-test dependency. The exposed parser API gave a fast syntax-only check without executing anything, which was ideal for CI-bound code. Parameter binding, JSON round-tripping and exit-code control were all straightforward, and behavior on Linux matched what I expected on Windows agents.

What got in the way

No packaged install was available in this environment, so I fetched and unpacked a release tarball by hand. Two language gotchas cost iterations: single-element and empty collections returned from functions unroll to a scalar or null, which then trips strict mode — easy to hit and not obvious from the error.

Authored a PowerShell runner for concurrent API checks, percentile comparison, error thresholds, and JUnit output. The local environment had no usable PowerShell executable, so the script could only be inspected and refined rather than executed end to end.

What worked

The language was expressive enough to keep request execution, baseline evaluation, and report generation in one pipeline-friendly script.

What got in the way

Local runtime validation was unavailable because PowerShell was not installed in the task environment.