2 Commits

Include renames

Author	SHA1	Message	Date
jcoffey-dev	30ae84cd04	Add sentry_notification_target, closing the alert-rule-as-code loop ... sentry_alert_rule.notification_target_id could previously only point at a target created outside Terraform (sentryctl/curl/the web UI) -- without this resource, "manage alert rules as code" was only half true. Same create/destroy-only shape as sentry_alert_rule and for the same reason: alerting has no PUT /targets/{id} either, confirmed down to notifystore.Store (Create/List/Get/Delete, no Update). client.go's notificationTarget type mirrors notifystore.Target's JSON shape. headers stays raw JSON bytes end to end -- the client has no opinion about its shape (neither does alerting's own Target type, json.RawMessage), and the resource layer round-trips it as a plain JSON-text string a caller provides via Terraform's jsonencode(). secret is marked Sensitive in the schema, but alerting's own GET /targets/{id} returns it unredacted (confirmed in notifystore/store.go -- no redaction at the store or handler layer, an existing property of alerting's API, not something this provider introduces). A new client test (TestGetNotificationTargetReturnsSecretUnredacted) documents that real behavior so a future change to it would be caught here, not discovered by surprise. Sensitive keeps the value out of plan/apply console output; it does not keep it out of Terraform state, the standard caveat for any sensitive attribute, named explicitly in the schema description and README rather than left implicit. Examples updated end to end: sentry_alert_rule's example now creates a real sentry_notification_target and references its .id, instead of a placeholder string. Verified: client tests are real httptest.Server round trips. Schema validation needs no Terraform binary. TestAccNotificationTargetResource_basic is a real acceptance test, skip-gated by TF_ACC same as the other two, including a plancheck.ExpectResourceAction assertion that a config change actually plans destroy-then-create, and (since secret really does round-trip unredacted) a real ImportStateVerify on the secret attribute rather than one papered over with ImportStateVerifyIgnore. Not run against a live stack in this environment, same disclosed gap as everything else Docker-gated in this repo.	2026-08-15 10:20:52 -07:00
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