Fallback to installing AMD64 plugins on Darwin #491
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.
What this PR does / why we need it
With this PR it is now possible to fully use a locally built CLI on Mac ARM64 machines
Although the CLI is available for Darwin ARM64, the vast majority of plugins are not, and therefore an ARM64 CLI will not be able to install most plugins.
Thanks to Apple's Rosetta emulator available on Darwin ARM64 machines, it is possible to run AMD64 binaries. This is currently how the CLI and its plugins are being run.
This commit teaches a Darwin ARM64 CLI that if a plugin is not available for Darwin ARM64, it should instead install the Darwin AMD64 version. With this approach, it now become possible to use a Darwin ARM64 CLI to its full potential.
Note that this approach cannot be used for Linux as there is no standard emulator for AMD64 binaries. For Linux, plugins will need to be published for ARM64.
Unit tests have been added for this new feature.
Which issue(s) this PR fixes
Part of #357
Describe testing done for PR
Release note
Additional information
Special notes for your reviewer
Implementation approach
The implementation approach chosen is to replace the use of
runtime.GOOS/GOARCH
with our own versioncli.GOOS/GOARCH
everywhere in the code. The new variable are set to the same value as theruntime
ones. However, it now becomes possible to programatically make the CLI believe it is running on a different OS/ARCH (for this PR, we change the ARCH toAMD64
to install plugins not available for ARM64 on Darwin).An alternative approach would have been to add arguments to many different function to specify what ARCH should be used. This second approach would have required a bit more changes.
However, the real reason I opted for the first approach is that it also allows to write unit tests for this feature, even if those tests are run on Linux, or AMD64, by using the
cli.GOOS/GOARCH
to make the CLI believe it is running on Darwin ARM64 for the test in question.No E2E tests
To be able to use this feature, one must run on a Darwin ARM64 machine. Therefore to be able to exercise the feature in E2E tests, those tests would need to run on darwin_arm64, which is not something offered out-of-the-box for Github actions. Here are the options I can see:
I prefer option 3 but am open to other opinions or suggestions.
Other aspect
A aspect that I did NOT implement is the following: when running a Darwin AMD64 CLI on a Darwin ARM64 machine, we could install ARM64 plugins when available; now, and with this PR, an Darwin AMD64 will only install AMD64 plugins.
I opted against this because with this PR, there should be no reason to run an AMD64 CLI on a Darwin ARM64 machine. Therefore we should direct users to use the ARM64 CLI. Same goes for plugin devs. Note that 'brew install' will install the ARM64 CLI starting with the v1.1 version when on ARM64 Macs.
Besides, even if we did implement this extra "feature", a plugin dev would need to install the v1.1 CLI to benefit from it, which takes us back to: might as well install the ARM64 version of the CLI 1.1.