Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Simplify and generalize configurable working directory code in build …
…workflow 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. 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: * the value of the `runner.os` context item * 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. Removing the unnecessary condition makes the workflow easier to understand and maintain, and makes it possible to configure any job to use a custom working directory if necessary.
- Loading branch information