The unit and integration tests install various versions of Task.
The GitHub Actions macos-latest runner was recently changed from using x86 machines to Apple Silicon/ARM machines.
Task is now built for both architectures. However, this was not done for the older versions of Task previously used for the tests. The runner architecture switch caused the tests to start failing spuriously on the macos-latest GitHub Actions workflow run jobs:
```
FAIL __tests__/main.test.ts
installer tests
✕ Downloads version of Task if no matching version is installed (188 ms)
Gets the latest release of Task
✕ Gets the latest version of Task 2.5 using 2.5 and no matching version is installed (174 ms)
✕ Gets latest version of Task using 2.x and no matching version is installed (68 ms)
✕ Gets preview version of Task using 3.x and no matching version is installed (167 ms)
✕ Skips version computing when a valid semver is provided (164 ms)
● installer tests › Downloads version of Task if no matching version is installed
Failed to download version v2.6.0: Error: Unexpected HTTP response: 404
165 | core.debug(error.toString());
166 | }
> 167 | throw new Error(`Failed to download version ${version}: ${error}`);
| ^
168 | }
169 |
170 | // Extract
at src/installer.ts:167:11
at Generator.throw (<anonymous>)
at rejected (src/installer.ts:40:65)
● installer tests › Gets the latest release of Task › Gets the latest version of Task 2.5 using 2.5 and no matching version is installed
Failed to download version v2.5.2: Error: Unexpected HTTP response: 404
165 | core.debug(error.toString());
166 | }
> 167 | throw new Error(`Failed to download version ${version}: ${error}`);
| ^
168 | }
169 |
170 | // Extract
at src/installer.ts:167:11
at Generator.throw (<anonymous>)
at rejected (src/installer.ts:40:65)
● installer tests › Gets the latest release of Task › Gets latest version of Task using 2.x and no matching version is installed
Failed to download version v2.6.0: Error: Unexpected HTTP response: 404
165 | core.debug(error.toString());
166 | }
> 167 | throw new Error(`Failed to download version ${version}: ${error}`);
| ^
168 | }
169 |
170 | // Extract
at src/installer.ts:167:11
at Generator.throw (<anonymous>)
at rejected (src/installer.ts:40:65)
● installer tests › Gets the latest release of Task › Gets preview version of Task using 3.x and no matching version is installed
Failed to download version v3.0.0-preview1: Error: Unexpected HTTP response: 404
165 | core.debug(error.toString());
166 | }
> 167 | throw new Error(`Failed to download version ${version}: ${error}`);
| ^
168 | }
169 |
170 | // Extract
at src/installer.ts:167:11
at Generator.throw (<anonymous>)
at rejected (src/installer.ts:40:65)
● installer tests › Gets the latest release of Task › Skips version computing when a valid semver is provided
Failed to download version v3.0.0: Error: Unexpected HTTP response: 404
165 | core.debug(error.toString());
166 | }
> 167 | throw new Error(`Failed to download version ${version}: ${error}`);
| ^
168 | }
169 |
170 | // Extract
at src/installer.ts:167:11
at Generator.throw (<anonymous>)
at rejected (src/installer.ts:40:65)
```
```
Error: Failed to download version v3.4.1: Error: Unexpected HTTP response: 404
```
The obvious solution would be to pin the runner to the last x86 runner: macos-13 in the test runner workflows. However, GitHub phases out runners over time so this would not be a future proof solution. The chosen solution is to continue to use the Apple Silicon macos-latest runner and adjust the tests to use versions of Task for which an Apple Silicon build is available.
This was not possible for the integration test of the action's major version pinning capability. The reason is that a previous major version (2.x) must be used in this test in order to allow a consistent assertion, since the installed version would change over time if the latest major version was used. Apple Silicon builds are not available in the 2.x Task version series. For this reason, the integration test runner workflow is configured to skip that test on the macos-latest runner job. The Linux and Windows integration test runner jobs, as well as unit test (which is not constrained in this way due to using artificial tags data) will provide sufficient coverage for this capability.
There are two file extensions in common use for YAML files: `.yaml` and `.yml`. Although this project uses `.yml`
exclusively for YAML files, these are standardized workflows which might be applied to projects that have established the
use of the other extension. It will be most flexible if it supports both.
Change project name to "arduino/setup-task"
The Task documentation consistently refers to the tool as "Task". Taskfile is the term used for Task's configuration file.
This action is setting up the Task tool, not setting up the Task configuration file, so "arduino/setup-task" is more
appropriate than "arduino/setup-taskfile".
Building will now be done in the same commit as the changes to the source code, so doing it in the integration test
workflow is pointless, only making the CI slower and the maintenance burden greater.
