Skip to content

refactor: declare the property task fields once - #468

Merged
josegonzalez merged 1 commit into
mainfrom
454-extract-a-shared-propertyfields-struct-across-the-property-tasks
Aug 12, 2026
Merged

josegonzalez merged 1 commit into
mainfrom
454-extract-a-shared-propertyfields-struct-across-the-property-tasks

Conversation

@josegonzalez

Copy link
Copy Markdown
Member

The twenty-seven property tasks each restated the same app, global, property, value, state field set, so every cross-cutting change had to be applied twenty-seven times by hand. They now name a defined type over the shared PropertyFields, or over SensitivePropertyFields for a plugin whose values can be credentials. A defined type rather than an embedded struct keeps the field set flat to reflection, so the catalog, the required-field walk behind missing_required_field, the identity walk that names an unnamed task and the sensitive-value walks read the fields exactly as before. The parameter descriptions become plugin-agnostic as a result, which is what regenerates the task pages; the page title, synopsis and Properties table already name the plugin. Fixes #454.

dokku_scheduler_docker_local_property and dokku_service_property address their resources differently and keep their own fields, listed with the reason in propertyTasksWithOwnFields. TestPropertyTasksDeclareTheSharedFields fails the build for any other *_property task that restates the shared set, comparing struct tags rather than using ConvertibleTo, which ignores exactly the difference that matters. TestSensitivePropertyFieldsMatchesPropertyFields keeps the two shared types from drifting apart in anything but the sensitive tag on value.

The three toggle tasks carry the same duplication at smaller scale; that is #467 rather than part of this change.

The twenty-seven property tasks each restated the same `app`, `global`, `property`, `value`, `state` field set, so every cross-cutting change had to be applied twenty-seven times by hand. They now name a defined type over the shared `PropertyFields`, or over `SensitivePropertyFields` for a plugin whose values can be credentials. A defined type rather than an embedded struct keeps the field set flat to reflection, so the catalog, the required-field walk behind `missing_required_field`, the identity walk that names an unnamed task and the sensitive-value walks read the fields exactly as before. The parameter descriptions become plugin-agnostic as a result, which is what regenerates the task pages; the page title, synopsis and Properties table already name the plugin. Fixes #454.
@josegonzalez
josegonzalez merged commit 75f5f56 into main Aug 12, 2026
19 checks passed
@josegonzalez
josegonzalez deleted the 454-extract-a-shared-propertyfields-struct-across-the-property-tasks branch August 12, 2026 20:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Extract a shared PropertyFields struct across the property tasks

1 participant