2 Commits

Include renames

Author	SHA1	Message	Date
jcoffey-dev	b98f397221	Add sentry_alert_rule, the Terraform provider's second resource ... Confirmed with the project owner first: alerting's REST API has no PUT /rules/{id} at all -- confirmed down to rulestore.Store, which has Create/List/Get/Delete but no Update method to even wire one to, a real pre-existing gap in alerting's own API, not something new to this task. Decided to model sentry_alert_rule as create/destroy only rather than fake an in-place update via delete-then-recreate inside the resource: every attribute carries a RequiresReplace plan modifier, so a config change destroys and recreates the rule, surfacing in the plan output the real side effect that has (alert_state/delivery-log continuity resets) instead of hiding it. Adding a real PUT /rules/{id} to alerting would remove this constraint but is a change to a different module's REST API, out of scope here. internal/provider/client.go's new rule type and createRule/getRule/ deleteRule methods talk the exact same JSON contract sentryctl alerts apply already uses against alerting/internal/httpapi. GET /rules/{id} actually returns rulestore.RuleWithState (Rule's fields promoted via anonymous embedding, plus a "state" object) -- the local rule type has no field for "state" by design, and a new client test proves that extra key doesn't break parsing. alerting is a genuinely separate service from api (its own base URL), so this needed the provider to talk to more than one Sentry service for the first time: providerData now wraps two *client instances (api, alerting), with a new alerting_endpoint provider attribute defaulting the same way sentryctl's --alerting-api/$SENTRYCTL_ALERTING_API_URL does. dashboardResource's Configure updated to pull .api out of the new wrapper type instead of a bare *client. Schema mirrors sentry_dashboard's established pattern: comparator/ threshold_value/renotify_interval_minutes stay nullable (only meaningful for threshold-condition rules), enabled/for_minutes/query_language are Optional+Computed with a Terraform-side default matching the API's own default (true/0/"") rather than leaving the API as sole source of truth the way dashboard's default_earliest/default_latest deliberately do -- these three have no *pointer* type in the API's Rule struct, so their "default when omitted" is unconditional, not a real API-side default that could drift independently. Verified: client tests are real httptest.Server round trips (same pattern as sentry_dashboard's). Schema validation needs no Terraform binary. TestAccAlertRuleResource_basic is a real acceptance test, skip-gated by TF_ACC same as the dashboard one, including a plancheck.ExpectResourceAction assertion that a config change actually plans destroy-then-create -- the concrete, checked version of the "create/destroy only" design decision, not just a comment. Not run against a live stack in this environment, same disclosed gap as everything else Docker-gated in this repo.	2026-08-15 00:15:45 -07:00
jcoffey-dev	49dd050689	Start the Terraform provider: sentry_dashboard, the first resource ... CLAUDE.md names the Terraform provider a first-class deliverable alongside sentryctl ("CLI and Terraform provider are first-class, not afterthoughts"), but no phase before this one had actually built any of it -- no terraform/ directory existed. This is a first slice, not a finished provider: one resource, scoped and confirmed with the project owner before starting (a new pinned external dependency and an architectural decision not covered in /docs/architecture.md are both things CLAUDE.md's own "When in doubt" section says to ask about). New Go module (terraform/, github.com/sentry/sentry/terraform) built on HashiCorp's terraform-plugin-framework -- the actively-developed library, not the legacy SDKv2, since there's no existing provider code to migrate and no reason to start new on the framework HashiCorp itself steers people away from. internal/provider/client.go talks the exact same JSON contract sentryctl's "dashboards apply" and web's Export JSON button already use against api/dashboards.Handler (POST/GET/PUT/DELETE /dashboards[/{id}]) -- cli/README.md already named this "the seed of a future Terraform provider: one JSON contract, multiple callers," this is that third caller, not a new contract invented for Terraform's sake. sentry_dashboard's schema deliberately leaves default_earliest/ default_latest Optional+Computed with no Terraform-side static default, even though the API defaults them to "-1h"/"now" when empty -- letting the API stay the one source of truth for what "unset" means rather than duplicating that default in two places that could drift. tenant_id is Computed-only, matching api/dashboards.Handler's own tenantID() doc comment that a client-supplied value is always overridden server-side. Panels are not modeled by this resource -- a genuinely separate resource shape (own lifecycle, own endpoints, own validation needs), scoped out deliberately, not an oversight. Alert rules, notification targets, and tenant/RBAC resources are the same: real, disclosed future work, not attempted in this pass. See terraform/README.md for the full accounting. Verified: client_test.go runs real HTTP round trips against httptest. Server (request construction, response parsing, the 404-vs-other-error distinction Read/Delete need for Terraform's out-of-band-deletion convention) -- same pattern cli/cmd/sentryctl's own tests already use against the same api/dashboards endpoints. provider_test.go validates both schemas are internally well-formed without needing a Terraform binary. dashboard_resource_test.go's TestAccDashboardResource_basic is a real acceptance test (terraform-plugin-testing), skip-gated by TF_ACC=1 per that framework's own convention -- even with TF_ACC set it would still need a live api service (Postgres+ClickHouse) to apply against, which this environment has no Docker access to bring up, so it has not actually run here, same disclosed gap as every other live-infra test in this repo.	2026-08-15 00:06:26 -07:00