DBiLeSi opened a new issue, #8105: URL: https://github.com/apache/hop/issues/8105
### What would you like to happen? Apache Hop already lets users maintain a short description and longer extended description for workflows and pipelines in the Hop GUI properties. Hop Server also exposes workflowStatus / pipelineStatus pages and XML/JSON responses for running executions, but the server status UI currently focuses on execution status, action/transform details, logs, and the canvas preview rather than making the artifact description easy to see. As Hop projects grow more complex, it becomes increasingly important to understand not only what a workflow does, but also why it exists, what business process it supports, and what operational assumptions it has. Good action and pipeline names help explain the “what,” but they are not enough for the “why.” This is especially true in Hop Server, where users may monitor or trigger workflows remotely and may not be able to drill down easily into called pipelines and subworkflows from the server view. **Proposed Behavior** 1. Show the workflow or pipeline description and optionally extended description in the Hop Server workflowStatus and pipelineStatus HTML pages. 2. Include the same metadata in workflowStatus?json=Y, workflowStatus?xml=Y, pipelineStatus?json=Y, and pipelineStatus?xml=Y. 3. For asynchronous workflows or pipelines, make the artifact description available as an API Endpoint. 4. Optionally show descriptions for called child pipelines/subworkflows when that metadata is available. **Use Case** Teams often trigger Hop workflows remotely from external schedulers such as Rundeck, Apache Airflow, Control-M, Jenkins, Argo Workflows, Prefect, or Dagster. In those setups, descriptions are often duplicated in the scheduler UI because Hop Server does not expose the workflow/pipeline description clearly enough. If Hop Server returned the description and extended description, external schedulers could automatically sync that metadata from Hop. Teams would only need to maintain the description in one place: the Hop workflow or pipeline itself. **Why This Helps** - Makes Hop Server status pages easier to understand for operators. - Reduces duplicate documentation in external schedulers. - Helps teams maintain one source of truth for workflow purpose and operational context. - Improves supportability when projects contain many workflows, pipelines, and subworkflows. - Helps explain the “why” behind a workflow, not just the action sequence. **Suggested Acceptance Criteria** - workflowStatus HTML displays workflow description and has an expandable/collapsible area for extended description. - pipelineStatus HTML does the same for pipelines. - JSON/XML status responses include description and extendedDescription fields. - Empty descriptions are handled gracefully and do not clutter the UI. - Existing status behavior remains backward-compatible. ### Issue Priority Priority: 3 ### Issue Component Component: API -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
