Feature proposal: Generate safe-settings YAML from existing GitHub configuration (reverse sync)

已关闭
  • 哪里不对？
#994 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 6 天内回复

@decyjphr 已经在做这个了。

开始于 2026年6月4日。

  • #990 来自 @decyjphr —— 未关闭

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
停滞
技术栈
github, javascript
领域
api, backend, cli, devtools

调研方向

首先将提议的 generate-settings.js CLI 与 full-sync.js 进行比较，然后审查 lib/settingsGenerator.js 的 extractor 设计、现有 plugin 的 find() 方法以及 schema/settings.json。定义交集和覆盖行为，添加模拟 extractor 测试和往返测试，并验证 CLI 和 repository_dispatch 流程是否生成预期的文件或 PR。

由索引模型根据 Issue 内容生成。

描述

Summary

Today safe-settings applies declarative YAML config to GitHub. This proposal adds the reverse: generate repos/<name>.yml, suborgs/<name>.yml, and settings.yml from the current state of an org/repo. This helps teams onboard onto safe-settings without hand-authoring config for existing repositories.

Motivation
  • Onboarding existing orgs/repos requires manually transcribing current settings into YAML.
  • A generator bootstraps an accurate baseline config, which can then be refined and committed.
  • The generated files can be validated by feeding them back through safe-settings in nop (dry-run) mode — expecting zero diffs.
Proposed delivery

Two entry points sharing one extraction core:

  1. Standalone CLI (generate-settings.js, mirroring full-sync.js) — writes generated files to the local filesystem.
  2. App trigger via a repository_dispatch event (event_type: safe-settings-generate) — opens a PR against the admin repo with the generated file(s).

Client payload:

{
  "event_type": "safe-settings-generate",
  "client_payload": {
    "source_type": "repo | custom-property | org",
    "source_value": "<repo-name> | <custom-property-value> | <org>",
    "overwrite": false
  }
}

When overwrite: false (default) and the target file already exists, the generator writes <name>.sample.yml instead of replacing it.

Design

A new lib/settingsGenerator.js defines an extractor registry: section → "read current state".

  • Diffable plugins (labels, collaborators, teams, milestones, autolinks, environments, custom_properties, variables, rulesets) reuse each plugin's existing find() method, then sanitize API-only fields (id, node_id, url, timestamps, read-only props).
  • Non-diffable sections need custom reads: repository (repos.get) and branches (list protected branches + getBranchProtection).
  • Output serialized with js-yaml, optionally validated against schema/settings.json.

Scope behavior:

source_type What we can extract Output file
repo All repo-level plugins repos/<repo>.yml
org Org rulesets + custom repository roles only settings.yml
custom-property (suborg) Repo-level settings common to all matching repos suborgs/<value>.yml
Open question: how to derive sub-org settings

Sub-orgs represent settings common to a collection of repos. The proposed approach: discover all repos matching the custom property value, extract each repo's config, then reduce by intersection — keep only settings identical across all matching repos (arrays matched by MergeDeep.NAME_FIELDS). A suborgproperties selector is prepended. Alternatives considered: union (risks conflicts) or a single representative repo. Feedback welcome on the intersection strategy and whether to also report per-repo differences.

Scope boundaries
  • Secrets are never read (no secrets plugin exists); only API-readable values are emitted, with names/placeholders where values are unreadable.
  • validator is excluded (meta plugin).
  • Round-trip fidelity for branches/rulesets is the riskiest area; generated output will be gated by a nop round-trip test.
Verification plan
  • Unit tests per extractor + intersection + overwrite/.sample logic (mocked octokit).
  • Round-trip: feed generated repos/<name>.yml through safe-settings nop mode → expect zero diffs.
  • Manual dispatch produces a PR (or .sample file when overwrite: false).

Looking for community feedback before/while implementing, particularly on the sub-org intersection approach and the repository_dispatch payload shape.

主要语言
JavaScript
星标
930
派生
236
平均合并
13 天 22 小时
30 天内合并 PR
2

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

github-community-projects/safe-settings 的其他 Issue

查看 github-community-projects/safe-settings 的全部 Issue

相似的 Issue

更多 JavaScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。