Refactor the Java tooling as a CLI to allow easy additions

[batmat]

What feature do you want to see added?

It's a meta issue :). Chatting with @alecharp, he was interested in adding a way for someone to quickly see where they're declared as a developer in components. E.g. the recent case with Ivan who wants to stop maintaining some of his plugins, etc.

It would be nice that the tooling in the repo can support this. However, currently, the tools under src contain many main() that are called separately.

I'm thinking refactoring these as a single CLI with subcommands would allow adding new subcommands, parameters etc. more easily.

I'm willing to work on this, if that sounds like a sensible path to follow.

WDYT?
Thanks!

Upstream changes

No response

[lemeurherve]

a way for someone to quickly see where they're declared as a developer in components

There is https://www.jenkins.io/doc/developer/publishing/source-code-hosting/, mentioned in the README:

repository-permissions-updater/README.md

Line 116 in 8a4be28

Be sure to check [which users have commit access](https://www.jenkins.io/doc/developer/publishing/source-code-hosting/) to your repository and remove any that are unexpected before enabling CD, as well as any unexpected [deploy keys](https://docs.github.com/en/developers/overview/managing-deploy-keys).

May worth some emphasis for better discoverability?

[lemeurherve]

Also worth noting in case of refactor, a previous effort to manage GitHub permissions as code that could be nice to revisit: #3998

[daniel-beck]

There is

Careful, "developers" in this repo can deploy new releases (and are generally considered "owners" who get to make certain decisions). Committers (what the linked page shows) have GitHub commit permissions. Completely different and independent systems and permissions.

[daniel-beck]

interested in adding a way for someone to quickly see where they're declared as a developer in components

To what degree is that not taken care of by a basic GH search? Teams complicate that a bit, but otherwise? Besides grep and equivalents, there's yq / shyaml to parse YAML files. The Jenkins security team has been doing that for years to add the appropriate folks as assignees to security issues.

Not saying this shouldn't be done (it would probably simplify things on our side long term 😄), but the stated motivation seems a bit weak.

[batmat]

@danielbeck You're right - grep works fine for finding. But if we can make this easier for non-experts twiddling with RPU files, I'm hoping such higher-level commands would also help the security team that already knows how to handle all this stuff. Saving time is kind of the essence these days 😅

it would probably simplify things on our side long term

TBH, that's also where I'm coming from 😄. I can file a minimal PR to show what it would look like. I think this would only improve the situation. And hopefully, even if hypothetic I agree, it may ease future improvements.

Sound reasonable?

[batmat]

Not sure the automated link posted an update here: FYI, I filed a first minimal PR implementing this #4758

[batmat]

This was merged. Thanks Tim!