chore: regenerate models from upstream schemas #59

Merged

stack72 merged 1 commit from automated/regenerate-models into main 2026-06-17 14:30:06 +00:00

Conversation 1 Commits 1 Files changed 24 +2042 -67

stack72 commented 2026-06-17 06:10:43 +00:00

Owner

Copy link

Summary

Automated regeneration of extension models from upstream provider schemas.

Schema Sources

• AWS: CloudFormation Resource Schema
• GCP: Google Discovery Documents
• Hetzner: Hetzner Cloud OpenAPI spec
• DigitalOcean: DigitalOcean OpenAPI spec

Review Notes

• Files under model/ are auto-generated — review the manifest.yaml diffs for version changes
• CalVer versioning with content-based change detection ensures versions only bump when content changes
• Publishing happens automatically when this PR is merged (via the publish workflow)

## Summary Automated regeneration of extension models from upstream provider schemas. ### Schema Sources - **AWS**: CloudFormation Resource Schema - **GCP**: Google Discovery Documents - **Hetzner**: Hetzner Cloud OpenAPI spec - **DigitalOcean**: DigitalOcean OpenAPI spec ### Review Notes - Files under `model/` are auto-generated — review the `manifest.yaml` diffs for version changes - CalVer versioning with content-based change detection ensures versions only bump when content changes - Publishing happens automatically when this PR is merged (via the publish workflow)

stack72 added 1 commit 2026-06-17 06:10:43 +00:00

chore: regenerate models from upstream schemas (2026-06-17) cefb15be03

stack72 commented 2026-06-17 06:22:57 +00:00

Author

Owner

Copy link

Code Review

Blocking Issues

1. Model files contain schema-level changes with no corresponding codegen/ changes.

   Every changed file is under model/, but the changes go well beyond version/upgrade entries. Across the diff, the following substantive schema changes appear:

   • harness.ts — 10+ new Zod schema objects (S3FilesAccessPointConfigurationSchema, EfsAccessPointConfigurationSchema, SelfManagedLatticeResourceSchema, ManagedVpcResourceSchema, PrivateEndpointSchema, PrivateEndpointOverrideSchema, HarnessLiteLlmModelConfigSchema, HarnessSkillS3SourceSchema, HarnessSkillGitAuthSchema, HarnessSkillGitSourceSchema), new fields on existing schemas
   • elasticloadbalancing/ — entirely new service directory (load_balancer.ts, _lib/aws.ts, deno.json, deno.lock, manifest.yaml, etc.)
   • cluster.ts — new SharedEnvironmentConfigSchema, new RestrictedInstanceGroupsConfig field
   • origin_endpoint.ts — new AudioTimelinePattern enum field, two new ScteSchema enum values
   • clusters.ts / clusters_nodepools.ts — imageFamily field removed from multiple schema locations
   • matters_holds.ts — new geminiQuery field
   • Various files — description text updated on existing fields

   Per CLAUDE.md, files under model/ are auto-generated and must never be hand-edited. The review rules identify two legitimate cases for model-only changes: (a) codegen regeneration where codegen/ also changes, or (b) pure version bumps via the bump-versions script (only version, upgrades, and manifest entries change). This PR is neither — it has structural schema changes without any codegen/ changes.

   The commit message says "chore: regenerate models from upstream schemas", suggesting these were produced by running deno task fetch-schema:<provider> followed by deno task generate:<provider>. If so, the pipeline should be run again and the resulting diff verified to confirm the output is identical (idempotency check), and the PR description should note which upstream schema fetch produced these changes. Without that verification, it is indistinguishable from hand-editing.

   Resolution: Re-run the full fetch + generate pipeline, verify idempotency (running generate a second time produces zero new diffs), and confirm the model/ diff matches what is in this PR. If the codegen pipeline itself needed changes to produce this output, those changes must be included.

Suggestions

None.

## Code Review ### Blocking Issues 1. **Model files contain schema-level changes with no corresponding `codegen/` changes.** Every changed file is under `model/`, but the changes go well beyond version/upgrade entries. Across the diff, the following substantive schema changes appear: - `harness.ts` — 10+ new Zod schema objects (`S3FilesAccessPointConfigurationSchema`, `EfsAccessPointConfigurationSchema`, `SelfManagedLatticeResourceSchema`, `ManagedVpcResourceSchema`, `PrivateEndpointSchema`, `PrivateEndpointOverrideSchema`, `HarnessLiteLlmModelConfigSchema`, `HarnessSkillS3SourceSchema`, `HarnessSkillGitAuthSchema`, `HarnessSkillGitSourceSchema`), new fields on existing schemas - `elasticloadbalancing/` — entirely new service directory (`load_balancer.ts`, `_lib/aws.ts`, `deno.json`, `deno.lock`, `manifest.yaml`, etc.) - `cluster.ts` — new `SharedEnvironmentConfigSchema`, new `RestrictedInstanceGroupsConfig` field - `origin_endpoint.ts` — new `AudioTimelinePattern` enum field, two new `ScteSchema` enum values - `clusters.ts` / `clusters_nodepools.ts` — `imageFamily` field removed from multiple schema locations - `matters_holds.ts` — new `geminiQuery` field - Various files — description text updated on existing fields Per CLAUDE.md, files under `model/` are **auto-generated and must never be hand-edited**. The review rules identify two legitimate cases for model-only changes: (a) codegen regeneration where `codegen/` also changes, or (b) pure version bumps via the `bump-versions` script (only `version`, `upgrades`, and `manifest` entries change). This PR is neither — it has structural schema changes without any `codegen/` changes. The commit message says "chore: regenerate models from upstream schemas", suggesting these were produced by running `deno task fetch-schema:<provider>` followed by `deno task generate:<provider>`. If so, the pipeline should be run again and the resulting diff verified to confirm the output is identical (idempotency check), and the PR description should note which upstream schema fetch produced these changes. Without that verification, it is indistinguishable from hand-editing. **Resolution**: Re-run the full fetch + generate pipeline, verify idempotency (running generate a second time produces zero new diffs), and confirm the `model/` diff matches what is in this PR. If the codegen pipeline itself needed changes to produce this output, those changes must be included. ### Suggestions None.

stack72 merged commit c422c7d9b8 into main 2026-06-17 14:30:06 +00:00

stack72 deleted branch automated/regenerate-models 2026-06-17 14:30:06 +00:00

stack72 referenced this pull request from a commit 2026-06-17 14:30:07 +00:00

chore: regenerate models from upstream schemas (#59)

stack72 referenced this pull request 2026-06-18 06:23:13 +00:00

chore: regenerate models from upstream schemas #60

stack72 referenced this pull request 2026-06-23 23:10:00 +00:00

chore: regenerate AWS models from upstream schemas #62

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

swamp-club/swamp-extensions!59

No description provided.