Action does not check swift version before running, causing redundant install

[bdrelling]

Say that I want to run tests across a matrix of containers, and I want to ensure that Swift 5.6 is installed on the machine, and also that all containers do not have Swift installed, except one container that already has Swift 5.6 installed.

If I have the following step in my job:

- uses: swift-actions/setup-swift@v1
  with:
    swift-version: '5.6'

I would expect all of the containers to fetch and install Swift, but I would expect the container that already has 5.6 to verify that it's the correct version (in this case, 5.6.1 specifically), and if it is, to skip the install as it is unnecessary.

Instead, the action fetches and installs Swift on the container that already has the correct version installed.

This is currently impacting my workaround Swift 5.7 builds, as I was hoping to leverage just adding the swiftlang/swift:nightly-5.7-focal container if the swift version I needed matched 5.7. Instead, I need to skip the entire job and create a duplicate job without setup-swift because this action fails to fetch a version of Swift 5.7.

Error: Unexpected error, unable to continue. Please report at https://github.com/swift-actions/setup-swift/issues
[14](https://github.com/bdrelling/Template-Swift/runs/8262739395?check_suite_focus=true#step:4:16)
Version "5.7" is not available

Just to be clear, I understand there is a separate issue for Swift 5.7 support, but I am specifically saying that I think the action should not have thrown the above error, as the container this job executed on had Swift 5.7 properly installed.

[fwal]

Hi @bdrelling, thanks for your report!

The problem is that the action is configured to configure 5.6 and will do just that and will not account for "incompatible" (as in not requested) versions already being installed.

We could however introduce a setting ignoring install if "higher" versions are already installed as this is a separate behaviour than the original intention of the action.

One option right now could be to specify "5" as the requested version. That will tell the action to setup the highest version in the "5" main version range (currently 5.6.3) but it should then accept 5.7 if it's already installed.

Let me know your thoughts!

[bdrelling]

Hey @fwal, thank you for the reply.

I think it would make sense that if the version being requested does not resolve to the exact version installed, a new version should be downloaded.

For example, if I put 5.6, your action would resolve this to 5.6.1, and if 5.6.0 was installed, I would still expect the extension to fetch and install 5.6.1.

To further emphasize with your example, if I had 5 entered in the extension and 5.7 is installed, but your plugin resolves 5 as 5.6.1 (the latest valid toolchain), then I would expect it to install 5.6.1, since 5.7 is not yet available. But, if I put 5.7 into the requested version, and the version installed is the latest possible 5.7.x, then nothing should happen.

Hope this makes sense -- a bit tricky to talk about. I think what you're saying makes sense, I'm just not sure that always presuming "higher" is correct makes sense. Like, if I have 5.6.1 installed but I ask for explicitly 5.5, your tool should 100% still install 5.5.

Thanks again!