There are some unique characteristics of the self-hosted runner which the workflow code must accommodate. The default working directory of the self-hosted runner is not suitable to perform the build under because the the resulting folder structure produced paths that exceeded the ridiculously small maximum path length of Windows. So the workflow must be configured to use a custom working directory with a short path (C:\a).
This custom working directory must be used only for the job running on the self-hosted Windows runner so the working directory of the relevant workflow steps are configured using a ternary expression. Previously, this expression had multiple conditions:
the definition of a custom working directory value in the job matrix
The second condition is entirely sufficient. The use of the first condition only added unnecessary complexity to the workflow code, and imposed a pointless limitation of only allowing the use of the custom working directory system on Windows runners.
Change description
Remove the unnecessary condition from the ternary expressions used to configure the working directory of workflow steps.
This makes the workflow easier to understand and maintain, and makes it possible to configure any job to use a custom working directory if necessary.
Reviewer checklist
[ ] PR addresses a single concern.
[ ] The PR has no duplicates (please search among the Pull Requests before creating one)
[ ] PR title and description are properly filled.
[ ] Docs have been added / updated (for bug fixes / features)
Motivation
The Windows builds of the application are cryptographically signed. The signing requires an "eToken" hardware authentication device be connected to the machine performing the signing (https://github.com/arduino/arduino-ide/pull/2452). This means that it is necessary to use a self-hosted GitHub Actions runner for the Windows job of the build workflow rather than the runners hosted by GitHub.
There are some unique characteristics of the self-hosted runner which the workflow code must accommodate. The default working directory of the self-hosted runner is not suitable to perform the build under because the the resulting folder structure produced paths that exceeded the ridiculously small maximum path length of Windows. So the workflow must be configured to use a custom working directory with a short path (
C:\a).This custom working directory must be used only for the job running on the self-hosted Windows runner so the working directory of the relevant workflow steps are configured using a ternary expression. Previously, this expression had multiple conditions:
runner.oscontext itemThe second condition is entirely sufficient. The use of the first condition only added unnecessary complexity to the workflow code, and imposed a pointless limitation of only allowing the use of the custom working directory system on Windows runners.
Change description
Remove the unnecessary condition from the ternary expressions used to configure the working directory of workflow steps.
This makes the workflow easier to understand and maintain, and makes it possible to configure any job to use a custom working directory if necessary.
Reviewer checklist