Skip to content

Drop the Issue Reference From repo-config's Archived-Exemption Note #1893

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ptr727 merged 1 commit into from
Sep 26, 2026
+1 −1
Merged

Drop the Issue Reference From repo-config's Archived-Exemption Note #1893

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion repo-config/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ Hub-only repository and branch configuration held as committed files, kept out o
- `main.json`, `develop.json`, and `operational/develop.json`: the canonical branch rulesets as the managed part of the writable API subset (`name`, `target`, `enforcement`, `conditions`, `rules`). `main.json` is shared. `develop.json` serves release repos, and `operational/develop.json` serves operational repos. `repo-config/configure.sh check owner/repo release|operational` compares the selected payloads with the live rulesets. `bypass_actors` is writable and deliberately unmanaged, so no payload declares one and nothing diffs it: who may bypass a ruleset is a human decision taken in the UI, which `repo-config/configure.sh` preserves on `apply` and reports without asserting on `check`.
- `labels.json`: the fleet label set, one `name`, `color`, and `description` per label. `repo-config/configure.sh apply owner/repo release|operational` creates or updates every declared label by name and deletes nothing, so a label a repo adds of its own stays. `check` asserts each declared label on all three fields and reports the undeclared ones without judging them.
- `project.json`: the fleet project every repository is linked to, declared as the project owner, the project number, and the project title. `repo-config/configure.sh apply owner/repo release|operational` resolves the number to a live project, refuses the run when that project's title is not the declared one, and writes the link only when the repository does not already hold it, so a second apply is a read. `check` asserts the link and counts the repository's other project links without judging them, the same way it treats a label the payload never declared.
- `configure.sh`: run from a hub checkout at `main`, per [GOVERNANCE.md "Hub-Hosted Tooling"][governance-hub-hosted-tooling]. It resolves every payload path against the hub's `repo-config/` directory. Name the target repository explicitly, since the command defaults to whichever repository the shell is sitting in. `repo-config/configure.sh apply owner/repo release|operational` creates or updates the settings, Dependabot security features, labels, rulesets, and the fleet project link idempotently. `repo-config/configure.sh check owner/repo release|operational` is the read-only counterpart and exits non-zero on drift. It is not an exact inverse: it also asserts that every environment the registry's `environments` declares for the repo exists and carries the declared deployment-branch policy, neither of which `apply` writes, for the reason [docs/repo-config.md][repo-config-doc] "Deployment Environments" gives. The model defaults to the registry `workflowModel` lookup. Pass it explicitly for a repository outside the registry. Both commands exit early, writing nothing, when the target's registry entry carries `status: "archived"`: GitHub rejects every write to an archived repository, so `apply` could never clear the drift `check` would otherwise report there forever (#1671).
- `configure.sh`: run from a hub checkout at `main`, per [GOVERNANCE.md "Hub-Hosted Tooling"][governance-hub-hosted-tooling]. It resolves every payload path against the hub's `repo-config/` directory. Name the target repository explicitly, since the command defaults to whichever repository the shell is sitting in. `repo-config/configure.sh apply owner/repo release|operational` creates or updates the settings, Dependabot security features, labels, rulesets, and the fleet project link idempotently. `repo-config/configure.sh check owner/repo release|operational` is the read-only counterpart and exits non-zero on drift. It is not an exact inverse: it also asserts that every environment the registry's `environments` declares for the repo exists and carries the declared deployment-branch policy, neither of which `apply` writes, for the reason [docs/repo-config.md][repo-config-doc] "Deployment Environments" gives. The model defaults to the registry `workflowModel` lookup. Pass it explicitly for a repository outside the registry. Both commands exit early, writing nothing, when the target's registry entry carries `status: "archived"`: GitHub rejects every write to an archived repository, so `apply` could never clear the drift `check` would otherwise report there forever.

## Rulesets

Expand Down
Loading