Aller au contenu

Squash Orchestrator 4.15.0 Release Note

Introduction

Squash Orchestrator is a set of micro-services to perform automated test execution workflows described in a specific format.

This release note describes the changes of Squash Orchestrator version 4.15.0 compared to 4.14.0.

Squash Orchestrator 4.15.0 was released on December 3rd, 2024.

New features

  • Issue orchestrator #172 SoapUI - Pass parameters
    The SoapUI provider now supports parameters. Transmitted parameters are available through project properties (using the ${#Project#parameter_name} syntax). More information can be found on the SoapUI page.

  • Issue orchestrator #603 Use workflow labels to parameter /logs endpoint returned execution log
    It is now possible to customize the log level of the logs available in Squash TM (for both the live execution log and the file in the automated suite reports). This is done through three labels set in the workflow: live-executionlog/step-depth, live-executionlog/job-depth, and live-executionlog/max-command-length. These labels interact with the GET /workflows/${workflow_id}/logs endpoint. More information can be found here.

  • Issue python-toolkit #178 Add a ::download:: command to download artifacts to an execution environment
    Issue orchestrator #612 Add a function to download an artifact that was previously uploaded
    A new action actions/download-artifact@v1 enables users to download any artifact defined at the workflow level (e.g., artifacts uploaded using the actions/upload-artifact@v1). This new action supports three optional parameters, name, pattern, and path, as described here.

  • Issue python-toolkit #179 Allow for ':' in selector values
    opentf-ctl commands (and the related endpoints) accepting selectors (e.g., with the options --field-selector, --having, --selector) now accept colons (:) in the values of these ones.

  • Issue orchestrator #9 Bring back environment variables
    The behavior of OPENTF_VARIABLES has been improved to ensure that these variables are accessible in the variables context. This means that a variable set in a step can be used later in the workflow, for example for a condition. More information can be found here.

  • Issue orchestrator #627 The execute function should not generate allure items in RobotFramework provider if allure report generation is disabled
    Robot Framework will now stop generating Allure attachments if the environment variable OPENTF_ALLURE_ENABLED is not correctly set. This should improve the execution time in this specific case.

  • Issue orchestrator #611 Reduce the number of steps for common providers (part 2)
    Following the previous release, additional optimizations have been made to reduce the number of steps generated for some providers (Cucumber, Cypress, JUnit, Playwright, Postman, SKF, and SoapUI), potentially improving the overall execution time.

  • Issue orchestrator #609 Study insight cache usage
    Memory usage for the insight cache has been improved by applying filters to the cached data. This should improve the time necessary to generate insight reports, especially for longer workflows.

Bug fixes

  • Issue orchestrator #614 Long-running agents are reported as unreachable
    An agent executing long-running steps could appear as UNREACHABLE when the step execution exceeded the LIVENESS_PROBE parameter. The agent now remains as BUSY during such scenarios.

  • Issue orchestrator #613 Stacktraces in html reports are hard to read
    Failure details in HTML reports were not correctly formatted for some technologies, and the output did not match what was shown in the console. This has been corrected to ensure consistent formatting.

  • Issue orchestrator #600 After a WorkflowCancellation the orchestrator will wait until a top-level step and its hook are completed before the WorkflowCancel
    Previously, after manually canceling a workflow, the workflow continued executing steps from hooks before stopping correctly. The process has been improved, ensuring proper cancellation. More information can be found here.

  • Issue orchestrator #610 Insights should be generated after workflow workers completion
    Previously, an insight report could be generated before all the results were available. This has now been fixed, the generation will now only start after all the workflow's workers have completed.