Description of feature
Nothing in docket says what identifies the resource a task manages. Every task knows it implicitly - dokku_config is keyed by app, a property task by app or global plus property, dokku_http_auth_user by app plus username, dokku_service_property by service plus name plus property - but that knowledge only exists in the shape of each task's required:"true" fields and in the head of whoever wrote it.
The closest thing to it is identifyingBodyField in commands/list_tasks.go, which walks the struct for the first non-empty string field named App, Name, Service, Repository, Mount, or Url. That is a display heuristic for --list-tasks output and it is documented as one; it picks App for dokku_docker_options and so collapses every phase and option on an app to the same label.
Two things suffer from this today. The name on a task envelope is the only correlation key in the --json event stream, and when a recipe omits name the value is generated by generateTaskName, which appends eight random bytes. Two runs of the same recipe therefore emit different name values for the same task, so a consumer diffing one run against another - a dashboard, a CI job comparing plan to apply - cannot line them up, and --start-at-task cannot name an unnamed task at all. And docket export reconstructs whole app plays, which is the only granularity it has; there is no way to read back one resource, because there is no way to say which one.
The ask is to write the keys down in a form the code can use. That could be an optional Identity() []string returning the field names that key the task, or a struct tag, or a table alongside appExportOrder. Whatever the form, it should make generateTaskName deterministic - a name derived from the task type plus its key fields is stable across runs, unique within a play in every case a random suffix was papering over, and considerably more readable in --list-tasks and in the event stream than task #3 9F2A1C4D. The set-valued tasks, dokku_domains and dokku_ports and dokku_acl_app, are the ones that need a decision rather than a mechanical answer: they key on app plus an unordered collection with no per-item identity.
Description of feature
Nothing in docket says what identifies the resource a task manages. Every task knows it implicitly -
dokku_configis keyed byapp, a property task byapporglobalplusproperty,dokku_http_auth_userbyappplususername,dokku_service_propertybyserviceplusnameplusproperty- but that knowledge only exists in the shape of each task'srequired:"true"fields and in the head of whoever wrote it.The closest thing to it is
identifyingBodyFieldincommands/list_tasks.go, which walks the struct for the first non-empty string field namedApp,Name,Service,Repository,Mount, orUrl. That is a display heuristic for--list-tasksoutput and it is documented as one; it picksAppfordokku_docker_optionsand so collapses every phase and option on an app to the same label.Two things suffer from this today. The
nameon a task envelope is the only correlation key in the--jsonevent stream, and when a recipe omitsnamethe value is generated bygenerateTaskName, which appends eight random bytes. Two runs of the same recipe therefore emit differentnamevalues for the same task, so a consumer diffing one run against another - a dashboard, a CI job comparing plan to apply - cannot line them up, and--start-at-taskcannot name an unnamed task at all. Anddocket exportreconstructs whole app plays, which is the only granularity it has; there is no way to read back one resource, because there is no way to say which one.The ask is to write the keys down in a form the code can use. That could be an optional
Identity() []stringreturning the field names that key the task, or a struct tag, or a table alongsideappExportOrder. Whatever the form, it should makegenerateTaskNamedeterministic - a name derived from the task type plus its key fields is stable across runs, unique within a play in every case a random suffix was papering over, and considerably more readable in--list-tasksand in the event stream thantask #3 9F2A1C4D. The set-valued tasks,dokku_domainsanddokku_portsanddokku_acl_app, are the ones that need a decision rather than a mechanical answer: they key onappplus an unordered collection with no per-item identity.