### Summary CI/CD job on a Windows machine does not execute all steps of the `script` block when a `gradle` command has executed prior to this. When [executed on a Gitlab.com](https://gitlab.com/azuregos/gradle-runner-bug/-/pipelines) such scenario lead to a job timing out without any reason. On a managed GitLab instance with a docker-windows executor such jobs either terminate early without an error but not executing all `script` steps or terminates with an error that suggests that a corruption of the command by the runner has taken place (see [related issue](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27394)) ### Steps to reproduce 1. Configure GitLab CI/CD repository with a Job primed to be executed on a Windows runner 2. Ensure that gradle is available on the target machine 3. Execute the following: ``` script: - gradle init --type java-library - gradle build - Write-Output "1" - Write-Output "2" - Write-Output "3" - Write-Output "4" - Write-Output "5" - Write-Output "6" - Write-Output "7" - Write-Output "8" - Write-Output "9" - Write-Output "END" ``` ### Example Project Project on GitLab: https://gitlab.com/azuregos/gradle-runner-bug Branches: - **main** (with a reproducible bug) - **no-gradle** (same pipeline but without a `gradle` command being used that always works correctly) Example of the failed pipeline: https://gitlab.com/azuregos/gradle-runner-bug/-/jobs/2079216393 Example of the pipeline that passed: https://gitlab.com/azuregos/gradle-runner-bug/-/jobs/2079298938 ### What is the current *bug* behavior? Runner does not execute all steps of the `script`. ### What is the expected *correct* behavior? An entire `script` block must be executed