feat(govern): add a context schema for the settings enforcement triggers

Dominic Bauerrequested to merge
db/settings-trigger-context-schemas into main

What does this MR do and why?

This MR registers the project_settings context schema for the three settings enforcement trigger ids from the monolith experiment: project_settings_updated, project_created, and project_settings_scheduled. Until now no schema existed for these ids, so every settings evaluation emitted a SCHEMA_NOT_FOUND diagnostic. Schema validation is diagnostics-only, so a violation or a missing schema never fails an evaluation. The change improves authoring feedback and makes disagreements between the context builder and the documented input.* contract visible.

All three ids point at one schema document because the monolith context builder emits the same settings snapshot at the save, creation, and scheduled moments. One policy rule can then run at any of them. At save time the snapshot holds the proposed values, the state as it would be after the write. The settings map holds the project's own stored column values because the policy checks compliance against the stored column. An ancestor's stricter value does not change what the map reports. The approval keys invert the monolith's disable-term columns into allow terms. The builder omits a key in three cases: an unlicensed tier, a missing backing storage row, or a nullable enum column with no stored choice. It writes no default for an omitted key.

The monolith renamed the trigger ids after this branch started. !309 (merged) builds on this MR and moves the registration to the renamed ids. Until it merges, the monolith builds its schema validation example with a pre-rename id and vendors the schema file as a CI fixture in gitlab-org/gitlab!261559 (merged). Group settings enforcement left the experiment, so this MR registers no group schema and replaces the earlier poc/settings-context-schemas branch.

References

Edited by Dominic Bauer

Merge request reports