feat: Support custom fields (metadata) on features, segments and environments - #245
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughThe provider adds custom metadata support for feature, segment, and environment resources and data sources. Metadata is validated against project custom fields, converted for API requests, and reconciled into Terraform state. Resources support metadata creation, updates, imports, and removal. Acceptance tests cover valid and invalid metadata. Documentation and examples describe configuration, validation, replacement behaviour, and imports. Estimated code review effort: 4 (Complex) | ~45 minutes Merge Risk: 🟡 Moderate · up to The PR adds custom metadata management to features, segments, and environments, but it is not merge-ready while clean checkouts cannot resolve the required API client dependency; CI and downstream builds will fail until a published version replaces the local module path. The environment import example also needs a shell-safe placeholder to avoid copy-and-paste errors. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
2896a73 to
8f080f2
Compare
fa7d38c to
092d965
Compare
8f080f2 to
c4a3508
Compare
092d965 to
479fb01
Compare
c4a3508 to
63fdc61
Compare
479fb01 to
4c3e001
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 19931e3e-2939-4689-935a-d43f989de9fa
📒 Files selected for processing (23)
.github/workflows/test.ymldocs/data-sources/feature.mddocs/data-sources/segment.mddocs/resources/environment.mddocs/resources/feature.mddocs/resources/segment.mdexamples/resources/flagsmith_environment/import-by-string-id.tfexamples/resources/flagsmith_environment/import.shexamples/resources/flagsmith_environment/resource.tfexamples/resources/flagsmith_feature/resource.tfexamples/resources/flagsmith_segment/resource.tfflagsmith/data_source_feature.goflagsmith/data_source_segment.goflagsmith/metadata.goflagsmith/metadata_test.goflagsmith/models.goflagsmith/models_test.goflagsmith/provider_test.goflagsmith/resource_environment.goflagsmith/resource_feature.goflagsmith/resource_metadata_test.goflagsmith/resource_segment.gogo.mod
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.
Adds a `metadata` attribute to the flagsmith_feature, flagsmith_segment and flagsmith_environment resources, so Flagsmith custom fields can be set from Terraform. Fixes #215: until now there was no way to set one, so an organisation with a mandatory custom field could not create features through the provider at all. Custom fields are keyed by name rather than by the numeric model field ID the API expects, since that ID is per (field, entity type) and is not portable across organisations: metadata = { "Jira Ticket" = "PROD-123" } The attribute is Optional and deliberately not Computed. The API replaces the whole set of custom field values on every write, so a value set in the UI on a Terraform managed resource is going to be removed either way; Optional+Computed would hide that in the plan and would also make it impossible to remove a value by deleting it from the configuration. That behaviour is worth calling out on its own: because the provider has never sent `metadata`, and the API defaults a missing key to an empty list, every apply that updated a feature, segment or environment was already destroying its custom field values silently. This change does not introduce that data loss, it makes it visible in the plan. Null and empty are kept distinct in state. Writing an empty map where the configuration had null produces "Provider produced inconsistent result after apply", and writing null where the configuration had `{}` produces a perpetual diff. Name resolution and the metadata endpoints are only touched when there are values to read or write, so anyone not using custom fields sees no additional requests, and older self hosted versions without custom field support are unaffected. Requires flagsmith-go-api-client v0.13.0. go.mod currently carries a local replace directive that must be swapped for the released version before this merges. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4c3e001 to
26fd7df
Compare
Drops the local `replace` directive pointing at ../flagsmith-go-api-client, which made a clean checkout unresolvable. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Terraform hard wraps diagnostic detail text, so "not enabled for features" was split across a line break and never matched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
6242f41
into
feat/feature-and-segment-data-sources
Closes #215.
Warning
Draft, and stacked on #244 — review that one first. Base will change to
mainonce it merges.Also blocked on flagsmith-go-api-client#23:
go.modcarries a localreplaceso this builds, so CI will fail ongo mod downloaduntil that's merged and released.Adds a
metadataattribute toflagsmith_feature,flagsmith_segmentandflagsmith_environment. Until now there was no way to set a custom field, so an organisation with a mandatory custom field couldn't create features through the provider at all — the symptom in the issue.Keyed by name rather than by the numeric model field ID the API wants, since that ID is per
(field, entity type)and isn't portable across organisations. The SDK resolves names to IDs and back.Worth calling out separately, because it changes what existing users see in a plan.
MetadataSerializerMixin._update_metadatain the API deletes and recreates the whole metadata set on every write, and is called unconditionally withvalidated_data.pop("metadata", []). Because the provider has never sentmetadata, and a missing key defaults to an empty list, every apply that updated a feature, segment or environment was already destroying its UI-set custom field values, silently.This PR doesn't introduce that. It makes it visible: a value set in the UI now shows up in the plan as an explicit removal, which you can act on.
Consequence for existing users: the first plan after upgrading may show a removal on resources that have UI-set custom fields. Add them to
metadatato keep them. This is in the CHANGELOG under NOTES.Filing an upstream issue to make an absent
metadatakey mean "no change" instead of "wipe" is worth doing regardless — it affects every API client, not just Terraform.🤖 Generated with Claude Code