tooling: Shift project tools to @envoy_repo

[phlax]

The @envoy_repo repository rule has historically provided a couple of things

• a PATH to the actual repo for tooling that makes changes to the files
• version info

recently - added to that is a json "config" that is derived from current project info by the project tooling

this PR groups the "meta" tooling that is used for managing changelogs, syncing, opening/closing branches etc - that is focused on querying or changing the state of the project (as described by the repo)

Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

[repokitteh-read-only]

CC @envoyproxy/dependency-shepherds: Your approval is needed for changes made to (bazel/.*repos.*\.bzl)|(bazel/dependency_imports\.bzl)|(api/bazel/.*\.bzl)|(.*/requirements\.txt)|(.*\.patch).
envoyproxy/dependency-shepherds assignee is @RyanTheOptimist

🐱

Caused by: #25605 was opened by phlax.

see: more, trace.

[phlax]

in this PR i have just moved the README, but i intend to follow up and incorporate some of the release info from elsewhere

cc @alyssawilk this makes use of the new proposed maintainer/ folder

[RyanTheOptimist]

Can you say more about the motivation for moving from "//tools/project" to "@envoy_repo://"? I understand what the former means when I see it ("look for a path named "tool/project" in the root of the Envoy tree) but I'm not as sure what "@envoy_repo" means. But presumably there is a good reason for doing this.

[phlax]

well currently this tooling is a bit obscure - but it is the authoritative way to open/close/etc the repo - so i think it makes more sense to groups these things in the repository rule

this is also a step in trying to unify some of the release documentation with newer workflows etc - and it feels like this would be better categorized as some workflows/methods for maintainers

[RyanTheOptimist]

Hm. Is there a practical difference between "@envoy_repo://foo" and "//tools/project"? Or is the former just "better" in some way? If so, can you can more about why it's better (perhaps in the PR description). You have a lot of context here so I'm certainly inclined to defer to your judgement. At the same time, I've never encountered "@envoy_repo" but have encountered "//tools/" so I'm naturally more inclined to the latter, especially as it appears that switching to "@envoy_repo" requires additional entries in repositories.bzl that we don't need when using "//tools/"

[phlax]

So for context @envoy_repo has historically provided a couple of things

• a PATH to the actual repo for tooling that makes changes to the files
• version info

recently - added to that is a json "config" that is derived from current project info by the project tooling (the same tooling that is used for managing changelogs, syncing, opening/closing branches etc)

so basically im trying to group that same tooling as a set of data and tools that is specifically focused on the project (as described by the repo)

technically there are some differences using a repository_rule as is done here but i think none that would preclude doing either way

semantically - separating this tooling here is saying that this is a set a meta targets outside the normal compile targets (and that change/query the state of the project)

i think using the (existing) repo_rule is probs the less controversial part of this PR than my desire to start grouping maintainer docs where i am - altho tbh my intention is mostly as here, to bring together existing docs from other parts of the repo to make them more coherent together, so im not sure thats so controversial either

[RyanTheOptimist]

Ah, thanks! That makes sense. Could you include some of that context in the PR description, for posterity? This seems like a reasonable approach to me. I suspect we should probably get a review from someone more familiar with using these tools, but this approach sounds good to me.

[phlax]

would be good to get a stamp from @alyssawilk re maintainer docs strategy

also worth mentioning is why i added the config object - its so we can generate dockerhub/github etc metatdata from templates and vars

[phlax]

also re using a repository_rule - the reason why this was done in the case of the version info originally is that ordinarily you cannot use information inside repo files (other than BUILD/bzl files) in the bazel rules - this allows us to do that - eg to create versioned packaging rules

[alyssawilk]

Honestly I have a slightly easier time when the tools live near the code so if something goes sideways I can fix inline. I don't grok to the move to a different repo (especially now we can avoid Envoy CI overhead for tools) but given you do 99% of our tooling I'm happy to sign off on what works for you :-)

[phlax]

/backport 1.23+

backporting this will make the maintainer docs consistent across release branches