fix(ci): don't use pip3 to install awscli

[rami3l]

The current stable CI is almost perfect except it gives this error on macos-14:

$ pip3 install awsclierror: externally-managed-environment× This environment is externally managed╰─> To install Python packages system-wide, try brew install xyz, where xyz is the package you are trying to install. If you wish to install a Python library that isn't in Homebrew, use a virtual environment: python3 -m venv path/to/venv source path/to/venv/bin/activate python3 -m pip install xyz If you wish to install a Python application that isn't in Homebrew, it may be easiest to use 'pipx install xyz', which will manage a virtual environment for you. You can install pipx with brew install pipx You may restore the old behavior of pip by passing the '--break-system-packages' flag to pip, or by adding 'break-system-packages = true' to your pip.conf file. The latter will permanently disable this error. If you disable this error, we STRONGLY recommend that you additionally pass the '--user' flag to pip, or set 'user = true' in your pip.conf file. Failure to do this can result in a broken Homebrew installation. Read more about this behavior here: <https://peps.python.org/pep-0668/>note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.hint: See PEP 668 for the detailed specification.

This is actions/runner-images#8615; it so happened that when we were releasing v1.27.0, pip3 was on Python v3.11, so that didn't bring up any error message.

Since awscli is already bundled in macos-(12|14) and ubuntu-*, pip3 install awscli actually has no effect. I think it’d be better to make the installation line a version check instead.
For windows runners, the existing awscli is already choco-managed, so there's nothing to be done.

It's worth noticing that the preinstalled awscli is on v2, but on pip we have awscli 1.32.89 as the latest version. However, given that we've already used the v2 for release purposes unintentionally for quite a while now, the differences here regarding the specific aws s3 cp command should be minimal.

This fix cannot be properly tested since it touches some part of the release process, but the aws --version part has been tested and is guaranteed to work.

[djc]

Nice work looking into this!