Add support for all Task build architectures #636
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, the action could only install Task when the GitHub Actions runner the workflow job was running on had an x86-64 or i386 architecture.
Since the GitHub-hosted runners are currently all x86-64, that is sufficient for most users. However, it is also possible to use GitHub actions with self-hosted runners of other architectures. Task builds are available for more architectures, so the action's code unnecessarily limited its utility.
Support for all architectures with available builds is hereby added.
In order to provide some possibility of automatic support for additional builds that may become available in the future, if the action code does not contain a mapped value for the host architecture, the value from Node.js is used verbatim. Because the mapping between the architecture value provided by Node.js to the filename suffix used in the Task build archives is a bit confusing, I added mapping entries for all suffixes, even in the cases where the two values are equal.
In order to provide a demonstration of the newly added architectures in use, I did a run of the integration test workflow with a job added to run it on a self-hosted runner I provided on an Apple Silicon (ARM64) macOS machine:
https://github.com/per1234/setup-task/actions/runs/4030927386
Unfortunately, adding such coverage as a permanent part of the repository's architecture would be problematic because our current approach for producing such a runner (AWS EC2 instance) incurs a significant charge to Arduino's AWS account for every workflow run. So I think we will need to be satisfied with the integration tests only providing coverage of the x86 runner architecture support and rely on manual/incidental testing for other runner architectures.