feat(76025): GitHub settings centralization one-pager solution proposal

[bogdandina]

No description provided.

[chihaiaalex]

Would look into the tool proposed by @haphut here #8 (comment), sounds like exactly what we need.

I’m not sure your proposal includes any use cases that the tool wouldn’t support. In any case, we can contribute there.

[bogdandina]

Would look into the tool proposed by @haphut here #8 (comment), sounds like exactly what we need.

I’m not sure your proposal includes any use cases that the tool wouldn’t support. In any case, we can contribute there.

Not yet. I was already working on the proposal and it was mostly done at the time. I will take a look at the proposed tool and come back with a conclusion.

[haphut]

Great work once again!

[haphut]

To make this slightly more confusing, there's also the official safe-settings. It would complicate the central management to use two tools but the division of responsibility between the two tools could look like this:

safe-settings:

• repository settings
• branch protection and rulesets
• auto-sync for new or drifting repos

bulk sync:

• unified dependabot.yml
• unified ci-cd.yml workflow files that use shared-workflows
  • "seed" the microservice repos with an auto-approve workflow and auto-merge setting to approve PRs from this central repo
• dry-run in PRs, act when merged to main

Unfortunately neither tool can unify microservice Dockerfiles but maybe that can be put on our wishlist. We can also wishlist repository templates that would include those microservice Dockerfiles. I think the return on investment for working on those is not high at the moment.

[haphut]

(There's also https://probot.github.io/apps/settings/ which was started by another GitHub employee but I don't think we should favour it over the other two.)

There are tools that do bulk file copying from a central repo to other repos, e.g. https://github.com/marketplace/actions/repo-file-sync-action , but I'm not happy using tools that are not from GitHub or creators with similar level of trustworthiness for such a security-critical need.

We need to tighten down the security to the max on this central management repo. Maybe use CODEOWNERS of our team members and require 1 or even 2 reviews from different CODEOWNERS before merging with exceptions disabled in the repo settings. Maybe even make the central management repo private just so no one outside of our team or GitHub org admins can make PRs to it.