feat: add database endpoints

[eduardoboucas]

No description provided.

[netlify]

✅ Deploy Preview for open-api ready!

Name	Link
🔨 Latest commit	78a6862
🔍 Latest deploy log	https://app.netlify.com/projects/open-api/deploys/69e9f695cdc1a50008fee77a
😎 Deploy Preview	https://deploy-preview-639--open-api.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• New Features
  • Added endpoints to list and retrieve database migrations with detailed information
  • Introduced database branch reset capability with optional force and role parameters
  • Expanded public API access for database management operations

Walkthrough

This pull request adds new Go models and HTTP client operations for database migration and branch reset functionality. The changes include five new Swagger-generated model types (DatabaseMigration, DatabaseMigrationDetail, ListDatabaseMigrationsResponse, ResetDatabaseBranchRequest, ResetDatabaseBranchResponse), three new API client operations with corresponding parameter builders and response handlers (GetSiteDatabaseMigration, ListSiteDatabaseMigrations, ResetSiteDatabaseBranch), updates to the main client service to integrate these operations, and corresponding OpenAPI spec additions defining three new endpoints and five new schema definitions.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	No pull request description was provided by the author, making it impossible to assess whether a description exists or is related to the changeset.	Add a description explaining the new database endpoints being introduced, their purpose, and any relevant implementation details or breaking changes.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'feat: add database endpoints' accurately and clearly summarizes the main change: introducing new database-related API endpoints and their supporting models.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/database

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

swagger.yml (1)

3647-3680: Consider the path parameter semantics overlap.

This endpoint uses GET /sites/{site_id}/database/migrations/{name} where {name} is the migration name, while the existing POST /sites/{site_id}/database/migrations/{deploy_id} at line 3681 uses {deploy_id} for running migrations.

While there's no technical conflict (different HTTP methods), the shared path structure with different parameter semantics could confuse API consumers. The descriptions clarify the distinction, so this is acceptable — just worth being mindful of in documentation.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@swagger.yml` around lines 3647 - 3680, The GET path operationId
getSiteDatabaseMigration currently uses
/sites/{site_id}/database/migrations/{name} while a POST uses
/sites/{site_id}/database/migrations/{deploy_id}, which conflates path
semantics; fix by choosing distinct path param names and documenting them—e.g.,
rename the GET path param from name to migration_name (update the parameters
block and description in getSiteDatabaseMigration) or change the POST path to
/.../migrations/deploys/{deploy_id} so the intent is explicit, and add a short
description to each operation clarifying that one identifies a migration by name
and the other references a deploy id; ensure both swagger definitions and any
$ref/operationId references are updated to match the new parameter names.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@swagger.yml`:
- Around line 3647-3680: The GET path operationId getSiteDatabaseMigration
currently uses /sites/{site_id}/database/migrations/{name} while a POST uses
/sites/{site_id}/database/migrations/{deploy_id}, which conflates path
semantics; fix by choosing distinct path param names and documenting them—e.g.,
rename the GET path param from name to migration_name (update the parameters
block and description in getSiteDatabaseMigration) or change the POST path to
/.../migrations/deploys/{deploy_id} so the intent is explicit, and add a short
description to each operation clarifying that one identifies a migration by name
and the other references a deploy id; ensure both swagger definitions and any
$ref/operationId references are updated to match the new parameter names.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: ddf2177a-2ea6-4571-a1f3-86a572451f70

📥 Commits

Reviewing files that changed from the base of the PR and between 0de7447 and 78a6862.

📒 Files selected for processing (13)

• go/models/database_migration.go
• go/models/database_migration_detail.go
• go/models/list_database_migrations_response.go
• go/models/reset_database_branch_request.go
• go/models/reset_database_branch_response.go
• go/plumbing/operations/get_site_database_migration_parameters.go
• go/plumbing/operations/get_site_database_migration_responses.go
• go/plumbing/operations/list_site_database_migrations_parameters.go
• go/plumbing/operations/list_site_database_migrations_responses.go
• go/plumbing/operations/operations_client.go
• go/plumbing/operations/reset_site_database_branch_parameters.go
• go/plumbing/operations/reset_site_database_branch_responses.go
• swagger.yml