Avoid sharing violations on event.json when using background steps on Windows

[smdn]

Description

This PR introduces a workaround to prevent file-locking errors (sharing violations) on Windows runners when using the new GitHub Actions background step feature.
To avoid code duplication caused by this workaround, YAML anchors and aliases are utilized.

Proposed Workaround

To safely bypass the file-locking issue on Windows, the following strategy is implemented:

1. Step Splitting via if conditions: The target step is split into two separate definitions - one for Windows (synchronous execution, background omitted) and one for non-Windows platforms (background: true).
2. Duplication Reduction via YAML Anchors (& / *): To avoid duplicating step properties (name, uses, with, env), the configuration is declared once in the Windows step and referenced in the non-Windows step.

Example Structure:

- name: &checkout_name "Checkout repository"
  if: runner.os == 'Windows'
  id: checkout-repository-win
  uses: &checkout_action actions/checkout@v4
  with: &checkout_config
    fetch-depth: 0

- name: *checkout_name
  if: runner.os != 'Windows'
  id: checkout-repository-posix
  uses: *checkout_action
  background: true
  with: *checkout_config

---

Appendix 1: Why This Workaround is Necessary (The Windows File-Locking Issue)

When using background: true asynchronously on Windows runners, workflows intermittently fail with the following error:

Error: The process cannot access the file 'D:\a\_temp\_github_workflow\event.json' because it is being used by another process.

Windows enforces strict file-locking mechanisms. When a step runs in the background, a race condition occurs with the runner or subsequent steps accessing event.json. Because this file is managed by the GitHub Actions infrastructure, direct user intervention or control over this behavior is not possible. This workaround ensures pipeline stability until a platform-side fix becomes available.

---

Appendix 2: Why Alternative Approaches Failed (Technical Limitations)

Ideally, the property would be dynamically toggled using GitHub Actions expressions:

# ❌ THIS FAILS AT PARSE TIME
background: ${{ runner.os != 'Windows' }}

However, verification confirms that the background property does not support runtime expressions. Attempting to use them results in the following parser errors, proving that these contexts are completely unresolvable within this scope:

• Unrecognized named-value: 'runner'
• Unrecognized named-value: 'matrix'
• Unrecognized named-value: 'inputs'

Therefore, splitting the steps using YAML anchors remains the only viable solution that maintains code readability.