Skip to main content

Module rules

Module rules 

Source
Expand description

The rules file: how each repository publishes a change.

YAML, first match wins. A rule matches on the host/owner/name of an identity or on a checkout path, and contributes whichever of the two policy fields it sets; anything it leaves unset comes from RulesFile::default.

What verifies a change is not here and never comes back. The repository’s own merge path is the verifier — the host’s required checks for an identity that publishes through a change request, the pre-push hook for one that publishes local-direct — and a second tier beside it front-ran the real one and threw the answer away.

These two fields are the whole of how an identity publishes. The registry records nothing about it: it used to infer a workflow and a repository type from whether the origin had a host, and every verb that routed on them — the merge train’s gate, the merge-path coverage verdict, the handoff naming the verb for a complete branch — routes on publication now, with approvals carrying the review requirement the repository type never actually carried. A rule matching an organisation (host and owner) is that organisation’s default, and one adding a name is the per-repository override; nothing else is needed to say that one hosted repository lands locally while its siblings open change requests.

Nothing here declares deny_unknown_fields, so a file a newer build wrote loads on this one: the keys it understands decide the policy and the rest are ignored. What that trades away is a typo being caught, and it is traded deliberately — an older build refusing an operator’s whole rules file stops every verb on the host. A key this build refuses by name is unaffected: the gate: version 3 removed is refused where the file is loaded, which is also the only place that knows which version declared it.

Structs§

Drafts
The drafts: mapping a rule and default: may carry: how a publication’s change request takes the draft lifecycle.
Policy
A complete policy: every field a rule may set, all of them decided.
Rule
One rule: what it matches, and which parts of the policy it sets.
RuleMatch
What a rule applies to. Every field is optional; the ones that are set must all match.
RulesFile
A rules file, as it is stored on disk.
TrailerPrefix
The prefix every provenance trailer key is spelled under.

Enums§

Approvals
Whether a change needs someone else’s approval before it may merge.
MergePolicy
How a change reaches the base branch.