chore: regenerate models from upstream schemas #14
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "automated/regenerate-models"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Automated regeneration of extension models from upstream provider schemas.
Schema Sources
Review Notes
model/are auto-generated — review themanifest.yamldiffs for version changesCode Review
Blocking Issues
Model files changed without corresponding codegen/ changes — All 30 changed files are under
model/, and several TypeScript model files contain substantive content changes (new schema fields, new enum values, new regex patterns, a new resource type) — not merely version/upgrade entries. Per CLAUDE.md, the only legitimate cases for model/ changes are (1) codegen regeneration where codegen/ also changes, or (2) pure version bumps affecting only version, upgrades, and manifest. This PR matches neither case as written.That said, there is strong circumstantial evidence this is a legitimate automated upstream-schema regeneration run and not hand-editing: the commit was made by
forgejo-actions[bot], the commit message ischore: regenerate models from upstream schemas (2026-05-29), every changed file carries the// Auto-generated … Do not edit manuallyheader, and the content changes are self-consistent with upstream schema evolution (new CVSS v4 fields in GCP containeranalysis, newPUBLIC_AND_PRIVATEenum value in MWAA, newKmsKeyArn/VpcConfigfields in Lambda, newAWS::VerifiedPermissions::PolicyStoreAliasresource).To unblock: Confirm idempotency by re-running
deno task generate:awsanddeno task generate:gcp(or the full regeneration workflow) and verifying the output matches this PR exactly with no new diffs. If the regeneration workflow in.forgejo/workflows/regenerate-models.ymlproduced this commit automatically, that fact should be surfaced in the PR so reviewers can skip the blocking flag. Consider also updating CLAUDE.md to explicitly describe this third legitimate case (automated upstream-schema regeneration where the codegen pipeline itself is unchanged).Suggestions
CLAUDE.md clarification — The current rule only lists two legitimate cases for model-only changes and would flag every automated upstream-schema regeneration PR as a potential hand-edit. Adding a third case — "automated regeneration where the codegen pipeline is unchanged but upstream schemas changed" — would reduce false positives in future reviews.
rule.tsregex change (^(?!aws:)[a-zA-Z+-=._:/]+$→^[a-zA-Z+-=._:/]+$) — the negative lookahead preventingaws:-prefixed keys was removed in this regeneration. This appears to follow the upstream CloudFormation schema change, but it is a functional constraint relaxation worth noting in release notes or a comment if AWS's actual enforcement has also changed.