…issions.

- Depends on XcodesOrg/xcodes#220

…issions.

- Depends on XcodesOrg/xcodes#220

…all` (#20672)

* Move helpers to a separate and centralized file.

* Deprecate 'xcode-install' gem (the project has been sunset), adding 'xcodes' action to replace the 'xcode_install' one.

* Add 'select_only' option to 'xcodes', deprecating 'xcversion' action.

* Update documentation to state it also supports .xcode-version file.

* Add TODO for a future improvement.

* Lint.

* Fix link.

* Remove TODO comment.

* Lint.

* Fix typo in error being raised.

* Add ability to select Xcode just for current build, without sudo permissions.
- Depends on XcodesOrg/xcodes#220

* Update documentation to point to 'xcodes' instead.

* Update xcodes link.

* Apply suggestions from code review.

Co-authored-by: Iulian Onofrei <[email protected]>

* Change "#" by "." in spec descriptions, to indicate class methods.

* Apply suggestion from code review.

* Improve documentation around requirements to run xcodes.

* Remove necessity to authenticate with Apple servers since xcodes v1.0.0.

* Use new --update and --selected arguments, which require xcodes v1.1.0.

* Fix comparing Gem::Version with String error

* Remove unused local variable

* Split long lines

* Fix lint issues

* Address style comments.

* Remove superfluous trailing slash

This makes it consistent with the rest of the codebase.

* Fix unsafe paths concatenation

* Fix some WWDR certificates test failure

This was caused by the fact that that test calls a method that uses `$?`
(https://stackoverflow.com/a/6834572/865175), which, somehow, (I think)
was executed right after a call to XcodesHelper's
`find_xcodes_binary_path` method. This latter one returned a non-zero
code, because `xcodes` can't be installed on Ubuntu, which got picked up
by the certificates return code check, so it treated its actual command
as failed.

* Replace `Actions.sh` call with a native one

(reverted from commit 11bd750)

* Fix error-prone shell command status check

In the case of the tests, `$?` was not mocked, so it looks like it was
indeed just a coincidence that it worked. Meaning, some other shell
command that somehow was actually executed (so it wasn't stubbed)
succeeded, which caused the `$?.success?` to succeed too.

Co-authored-by: Iulian Onofrei <[email protected]>
Co-authored-by: Iulian Onofrei <[email protected]>