Because the new tag is not created at this point, it should be ok to
just grab the latest one.

Signed-off-by: Adin Cebic <cebic.ad@gmail.com>

Fix after #3268, requires
bazelbuild/rules_apple#2880

Signed-off-by: Luis Padron <lpadron@squareup.com>

Signed-off-by: Adin Cebic <cebic.ad@gmail.com>
Signed-off-by: Brentley Jones <github@brentleyjones.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Adin Cebic <cebic.ad@gmail.com>

Signed-off-by: Aaron Sky <aaronsky@skyaaron.com>

Signed-off-by: Aaron Sky <aaronsky@skyaaron.com>

Iterating on #3266

- Bumps CI config to `[8.x, 9.x, last_green]`
  - Does not bump BCR tests – should we do that?
  - Does not fix HEAD tests due to patches needed in rules_apple
- Updates rules_apple, rules_swift, rules_cc, and more to align with
transitive deps required for Bazel 9 support
- Updates loads across the repo for newly-starlarkified things
(objc_library, cc_library, toolchain_utils.bzl, etc)
- Fixes some broken tests

---------

Signed-off-by: Aaron Sky <aaronsky@skyaaron.com>

This adds a build flag options to bypass the supported Xcode coverage
builds with `rules_xcodeproj`. We would find this flag useful for 2
reasons:
1. We have our own partially non-hermetic way to support coverage in
Xcode as well and would like to opt-out of this flag.
2. For some projects where we don't really need/want to support
coverage, sometimes developers happen to flip this flag anyways and end
up with suboptimal build times.

This just adds an opt-out flag in addition to the configured build
setting so that we can choose whether or not the project should use the
built-in coverage solution.

This can be enabled by adding
`--@rules_xcodeproj//xcodeproj:suppress_coverage_build` to your builds.

---------

Signed-off-by: sebastian.shanus <sebastian.shanus@robinhood.com>

[rules_ios is deprecated by its
maintainers](bazel-ios/rules_ios#952) and
being sunset. Its removal is of relevance to the removal of WORKSPACE
support from rules_xcodeproj. This PR removes the example from
`examples/rules_ios` (which haven't been building in CI for months now),
as well as mentions of support for it in the rules from supporting
documentation, but does not go out of its way to remove support for it
in the rules themselves.

Signed-off-by: Aaron Sky <aaronsky@skyaaron.com>

…m schemes (#3284)

Fixes #3283 

This takes a similar approach to how rules_apple handles infoplist
merging (take the union of top-level key/values, throw an error if a key
matches but a value does not).

Signed-off-by: Aaron Sky <aaronsky@skyaaron.com>

WORKSPACE is gone in Bazel 9, and was formally deprecated in Bazel 8.
We're preparing the rules for its removal across all supported versions.

ref bazelbuild/apple_support#487
ref bazelbuild/rules_swift#1613
ref bazelbuild/rules_apple#2814

---------

Signed-off-by: Aaron Sky <aaronsky@skyaaron.com>
Co-authored-by: Brentley Jones <github@brentleyjones.com>