Bazel: Improve dependency situation per #410

[cpsauer]

Fixes #410

[cpsauer]

(Failure is test infra failing to install bazelisk; will give a quick attempt at fixing.)

[thomasvl]

Thank you!

(nice that the github images include bazel now)

[cpsauer]

Thank you, Thomas! :)

[cpsauer]

While we're both here, a couple other upcoming Bazel things in my head that it occurred you might want a heads up on:
(1) As we get towards Bazel 7, the (Google) Bazel folks are likely to step up pressure to support bzlmod, their new package manager, which would require submitting PRs on each release. I've heard this is automatable with https://github.com/bazel-contrib/publish-to-bcr, but I'm not an expert yet.
(2) The rules_apple for internal development will, ofc, get out of date as time goes on. We could set up Renovate to auto-update it, so you can forget about it, as many Bazel repos have done. But I think only you can add GitHub apps, so you'd need to lead. I'd be happy to help with the config, though. Lmk if you want help there. On one hand it'll stop CI from ever breaking if rules_apple needs changes in step with Bazel. On the other, it has no impact on users since it's just the rules_apple version for tests; users are getting their own.

[thomasvl]

1. bzlmod seems like a direction we should move, rules_apple, rules_swift, apple_support seem to have already support it, so that likely could be done at any point.
2. I don't have any experience with Renovate. Could a github action that is set to run once a month be used to check and see if it time to update? I guess the best option would be something that would propose a PR to be approve when there was something to update.

[cpsauer]

1. Great! In that case, here's Use bzlmod internally #412, switching to bzlmod for building within this project, paving the way for you to do central repository releases whenever you're ready.
   I already had, in my head, a good idea of how we should do that part, so I figured I'd just knock it out. Unfortunately still don't have experience with the release automation stuff, but maybe we can share notes when either of us gets there on our projects :)
2. Renovate does exactly that by default: proposing PRs when there's something to update. (It can also auto-merge if checks pass--or do all that with branches to save you the email spam, which is what I'd advise, falling back to PRs if things fail.) It's used in lots of Bazel projects (including first-party) and is awesome, IMO. If you're interested, just add the app https://github.com/apps/renovate and I can help with config.

[thomasvl]

Since Renovate wants r/w permissions that's likely a no go for google repos. If you see something like that on another google repo, that's a pretty good sign it could be used here.

[cpsauer]

I'm pretty sure it's used in a bunch of Google repos--let me dig real quick

[cpsauer]

Yeah, sure is. If useful, here's a google org repo example: https://github.com/google/osv-scanner

And here's a bazelbuild org one https://github.com/bazelbuild/rules_kotlin

[cpsauer]

(I can see from their renovate.json files -- though I'd recommend renovate.json5)

(Could also use "Forking Renovate" which doesn't ask for code write permissions, but then also omits some of the most convenient auto-merge options. I haven't actually used that variant; I've always wanted the other features.)

[thomasvl]

I think I have the app installed (it send a PR to start), haven't tried to look at tuning the config once this first PR is merged.

[cpsauer]

Great! Lmk if you'd like my help configuring. Could, e.g. turn on silent auto-merge for rules_apple with

  "packageRules": [{ // If you want a package to update on autopilot and, whitelist it here avoid having automated PRs to review.
    "automerge": true, // Just automatically propose and merge in dependency upgrades to the latest.
    "automergeType": "branch", // No PR unless tests fail; just do it.
    "matchPackageNames" : [ // Add Bazel name= parameter here.
      "rules_apple",
    ],
  }],

The benefit would be that you'd be up to date by default and have one less thing to think about.

(IMO json->json5 is also fairly worth it for comments and allowing trailing commas to reduce diffs and issues there.)

[thomasvl]

Thanks, I think we'll keep it manual merges, we can always revisit that in the future. Probably doesn't hurt to let it keep an eye on the github workflow files.

[cpsauer]

Sure! Totally up to you, of course. Just want to make sure I'm making easy all the things I wish someone had told me when I got going with it. Thanks, Thomas!