[florentianayuwono]

Summary

JobExtensionL0.JobExtensionBuildStepsList fails on this fork's self-hosted CI runners with Assert.Equal(5, result.Count) → Actual: 6, identically on both the linux-x64 and linux-arm64 legs of #233's CI run. It is not architecture-specific, and does not reproduce in a clean local sandbox.

Root cause

JobExtension.InitializeJob reads two environment variables directly from the real OS process environment (not mocked/injected):

var startedHookPath = Environment.GetEnvironmentVariable("ACTIONS_RUNNER_HOOK_JOB_STARTED");
if (!string.IsNullOrEmpty(startedHookPath))
{
    preJobSteps.Add(new JobExtensionRunner(..., displayName: Constants.Hooks.JobStartedStepName, ...));
}

preJobSteps is merged directly into the step list returned by InitializeJob (steps.AddRange(preJobSteps); steps.AddRange(jobSteps);), so if this variable is set, the returned list silently grows by one.

JobExtensionL0's tests never cleared or mocked this variable, implicitly assuming it's always unset. That assumption doesn't hold on this fork's self-hosted CI fleet, which configures a job-started hook for its own lifecycle management — confirmed directly in the raw CI logs:

A job started hook has been configured by the self-hosted runner administrator

Because this is a real, process-level environment variable (not scoped to the outer GitHub Actions job wrapper), it's inherited by the child dotnet test process, so the inner unit test picks it up too — explaining why the failure is identical across architectures (same hook infra on every self-hosted runner) yet absent in any clean/non-hooked environment.

Fix

JobExtensionL0 now implements IDisposable:

• Constructor (runs before every test, since xUnit instantiates a new instance per test) captures the current value of ACTIONS_RUNNER_HOOK_JOB_STARTED and ACTIONS_RUNNER_HOOK_JOB_COMPLETED, then force-clears both.
• Dispose() (runs after every test) restores the original values.

This mirrors the env-var isolation pattern already used for the ARM32 kill-switch override tests (#232), properly isolating the test from ambient host/runner configuration instead of just assuming it away.

Testing

• dotnet build Test/Test.csproj -c Debug — builds cleanly, 0 warnings/errors.
• dotnet test --filter "FullyQualifiedName~JobExtensionL0" — 34/34 passed.

[florentianayuwono]

Consolidating this fix directly into #233 so CI goes green in one PR (this fix needed #233's build.yml matrix-condition change to actually exercise dotnet test on linux-x64/linux-arm64 anyway). Closing in favor of #233.