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.
GitHub downloads each action run in a workflow during runtime and executes it as a complete package of code before you
can use workflow commands like run to interact with the runner machine. This means that we must provide all JavaScript
package dependencies as part of the distributed action in order for it to be usable in workflows.
A naive approach to doing this is checking in the `node_modules` folder. However, this approach results in a huge amount
of frequently changing external content being included in the repository, much of which is not even part of the executed
program.
A far better approach is to use the excellent ncc tool to compile the program, including all the relevant code from the
dependencies, into a single file.
We use a "continuous packaging" approach, where the packaged action code that is generated via ncc is always kept in
sync with the development source code and dependencies. This allows a beta version of the action to be easily used in
workflows by beta testers or those who need changes not in the release simply by using the name of the branch as the
action ref (e.g., `uses: arduino/arduino-lint-action@main` will cause the version of the action from the tip of the
`main` branch to be used by the workflow run).
The update of the package dependency results in a change to the packaged code, so the packaging is here updated
accordingly.
The actions/setup-node GitHub Actions action is used to set up Node.js in the GitHub Actions runner machine.
The action supports obtaining the Node.js version to set up from the `engines.node` field of the package.json file.
This allows us to define the standardized version of Node.js for use by project contributors in a single place rather
than having to maintain multiple instances of that data.
It is not currently possible to bump the @typescript-eslint/eslint-plugin and @typescript-eslint/parser packages all the
way to the latest 8.0.0 version because the eslint-config-airbnb-typescript has a peer dependency on 7.x of those
packages. But it is at least possible to bump the eslint packages to 7.x, which must also be accompanied by the bump of
eslint-config-airbnb-typescript to 18.0.0.
GitHub downloads each action run in a workflow during runtime and executes it as a complete package of code before you
can use workflow commands like run to interact with the runner machine. This means that we must provide all JavaScript
package dependencies as part of the distributed action in order for it to be usable in workflows.
A naive approach to doing this is checking in the `node_modules` folder. However, this approach results in a huge amount
of frequently changing external content being included in the repository, much of which is not even part of the executed
program.
A far better approach is to use the excellent ncc tool to compile the program, including all the relevant code from the
dependencies, into a single file.
We use a "continuous packaging" approach, where the packaged action code that is generated via ncc is always kept in
sync with the development source code and dependencies. This allows a beta version of the action to be easily used in
workflows by beta testers or those who need changes not in the release simply by using the name of the branch as the
action ref (e.g., `uses: arduino/arduino-lint-action@main` will cause the version of the action from the tip of the
`main` branch to be used by the workflow run).
The update of the package dependency results in a change to the packaged code, so the packaging is here updated
accordingly.
GitHub downloads each action run in a workflow during runtime and executes it as a complete package of code before you
can use workflow commands like run to interact with the runner machine. This means that we must provide all JavaScript
package dependencies as part of the distributed action in order for it to be usable in workflows.
A naive approach to doing this is checking in the `node_modules` folder. However, this approach results in a huge amount
of frequently changing external content being included in the repository, much of which is not even part of the executed
program.
A far better approach is to use the excellent ncc tool to compile the program, including all the relevant code from the
dependencies, into a single file.
We use a "continuous packaging" approach, where the packaged action code that is generated via ncc is always kept in
sync with the development source code and dependencies. This allows a beta version of the action to be easily used in
workflows by beta testers or those who need changes not in the release simply by using the name of the branch as the
action ref (e.g., `uses: arduino/arduino-lint-action@main` will cause the version of the action from the tip of the
`main` branch to be used by the workflow run).
The update of the package dependency results in a change to the packaged code, so the packaging is here updated
accordingly.
