ldraney/godaddy-tofu

Fork 0

Implement godaddy_domains data source #14

New issue

Closed

opened 2026-06-14 17:27:04 +00:00 by ldraney · 1 comment

ldraney commented

2026-06-14 17:27:04 +00:00

Owner

Type

Feature

Summary

Implement data_source_domains.go to list and read domain details from GoDaddy. P1 priority.

User Story

As a platform operator, I want to list my GoDaddy domains via tofu plan so I can discover and reference domain properties.

Context

P1 priority — useful for discovery but not required for DNS record management. The client methods ListDomains and GetDomain are already implemented and tested.

Lineage

Parent: none
Story: domain-iac

Repo

godaddy-tofu

Scope

Create data_source_domains.go implementing datasource.DataSource interface
Schema: optional domain filter for single lookup
Read: client.ListDomains(ctx) or client.GetDomain(ctx, domain)
Output: domains list with domain_id, domain, status, expires, created_at
Register in provider.go DataSources() map

File Targets

data_source_domains.go (new)
provider.go (register data source)

Feature Flag

None

Test Expectations

Acceptance test in the acceptance tests issue
Manual: data "godaddy_domains" "all" {} lists domains

Acceptance Criteria

Lists all domains in GoDaddy account
Single domain lookup returns details
Output attributes populated correctly

Constraints

P1 — do after DNS resource and data source

Checklist

datasource.DataSource interface implemented
Registered in provider.go
Optional single-domain filter

Story: domain-iac
Lower priority than DNS resource/data source

### Type Feature ### Summary Implement `data_source_domains.go` to list and read domain details from GoDaddy. P1 priority. ### User Story As a platform operator, I want to list my GoDaddy domains via `tofu plan` so I can discover and reference domain properties. ### Context P1 priority — useful for discovery but not required for DNS record management. The client methods `ListDomains` and `GetDomain` are already implemented and tested. ### Lineage Parent: none Story: domain-iac ### Repo godaddy-tofu ### Scope - Create `data_source_domains.go` implementing `datasource.DataSource` interface - Schema: optional `domain` filter for single lookup - Read: `client.ListDomains(ctx)` or `client.GetDomain(ctx, domain)` - Output: `domains` list with domain_id, domain, status, expires, created_at - Register in `provider.go` DataSources() map ### File Targets - `data_source_domains.go` (new) - `provider.go` (register data source) ### Feature Flag None ### Test Expectations - Acceptance test in the acceptance tests issue - Manual: `data "godaddy_domains" "all" {}` lists domains ### Acceptance Criteria - [ ] Lists all domains in GoDaddy account - [ ] Single domain lookup returns details - [ ] Output attributes populated correctly ### Constraints P1 — do after DNS resource and data source ### Checklist - [ ] datasource.DataSource interface implemented - [ ] Registered in provider.go - [ ] Optional single-domain filter ### Related Story: domain-iac Lower priority than DNS resource/data source

ldraney commented

2026-06-14 17:48:44 +00:00

Author

Owner

Scope Review -- Dottie

Verdict: APPROVED

This ticket is clear, actionable, and ready for a dev agent.

1. Scope clarity

The scope section is well-defined: create data_source_domains.go, implement datasource.DataSource, wire it into provider.go. The schema, read logic, and output attributes are all specified. A dev agent can start coding immediately.

2. Acceptance criteria -- testable?

Yes. All three criteria are testable:

Lists all domains -- verifiable via ListDomains returning a non-empty list
Single domain lookup -- verifiable via optional domain filter calling GetDomain
Output attributes populated -- verifiable by checking domain_id, domain, status, expires, created_at are non-empty

Note: the ticket defers acceptance tests to a separate issue (#13 covers DNS; a domains acceptance test issue would be needed separately). For this ticket, manual validation (data "godaddy_domains" "all" {}) is sufficient.

3. File targets

Specified and correct:

data_source_domains.go (new) -- confirmed this file does not exist yet
provider.go (modify DataSources() to register) -- confirmed DataSources() currently returns an empty slice

4. Dependencies satisfied?

Yes. Verified against HEAD:

pkg/godaddy/domains.go contains both ListDomains(ctx) and GetDomain(ctx, domain) with correct signatures
pkg/godaddy/domains_test.go has passing integration tests for both methods
The Domain struct has all fields the ticket's output attributes reference (DomainID, Domain, Status, Expires, CreatedAt)
provider.go already imports the datasource package and has the empty DataSources() method ready for registration

5. Ambiguity check

No blockers found. Two minor observations (not blocking):

The Domain struct has many more fields than the five output attributes listed (e.g., Locked, Privacy, RenewAuto, NameServers). A dev agent should expose the five listed attributes at minimum; exposing additional fields is a judgment call but not ambiguous.
The DomainID field is int64 in Go but the ticket says domain_id in the output -- the dev agent should use types.Int64 in the Terraform schema, which is the obvious mapping.

Bottom line: Scope is tight, dependencies are met, file targets are accurate. Ready for implementation.

## Scope Review -- Dottie ### Verdict: APPROVED This ticket is clear, actionable, and ready for a dev agent. --- ### 1. Scope clarity The scope section is well-defined: create `data_source_domains.go`, implement `datasource.DataSource`, wire it into `provider.go`. The schema, read logic, and output attributes are all specified. A dev agent can start coding immediately. ### 2. Acceptance criteria -- testable? Yes. All three criteria are testable: - **Lists all domains** -- verifiable via `ListDomains` returning a non-empty list - **Single domain lookup** -- verifiable via optional `domain` filter calling `GetDomain` - **Output attributes populated** -- verifiable by checking `domain_id`, `domain`, `status`, `expires`, `created_at` are non-empty Note: the ticket defers acceptance tests to a separate issue (#13 covers DNS; a domains acceptance test issue would be needed separately). For this ticket, manual validation (`data "godaddy_domains" "all" {}`) is sufficient. ### 3. File targets Specified and correct: - `data_source_domains.go` (new) -- confirmed this file does not exist yet - `provider.go` (modify `DataSources()` to register) -- confirmed `DataSources()` currently returns an empty slice ### 4. Dependencies satisfied? **Yes.** Verified against `HEAD`: - `pkg/godaddy/domains.go` contains both `ListDomains(ctx)` and `GetDomain(ctx, domain)` with correct signatures - `pkg/godaddy/domains_test.go` has passing integration tests for both methods - The `Domain` struct has all fields the ticket's output attributes reference (`DomainID`, `Domain`, `Status`, `Expires`, `CreatedAt`) - `provider.go` already imports the `datasource` package and has the empty `DataSources()` method ready for registration ### 5. Ambiguity check No blockers found. Two minor observations (not blocking): - The `Domain` struct has many more fields than the five output attributes listed (e.g., `Locked`, `Privacy`, `RenewAuto`, `NameServers`). A dev agent should expose the five listed attributes at minimum; exposing additional fields is a judgment call but not ambiguous. - The `DomainID` field is `int64` in Go but the ticket says `domain_id` in the output -- the dev agent should use `types.Int64` in the Terraform schema, which is the obvious mapping. --- **Bottom line:** Scope is tight, dependencies are met, file targets are accurate. Ready for implementation.