From d9e2296a643de017dfe2442c7e08ca2fa0b158f4 Mon Sep 17 00:00:00 2001 From: Dave Craig Date: Mon, 8 Jun 2026 12:02:21 +0100 Subject: [PATCH] Add a maestro master flow and config to aid running on DeviceCloud I've been experimenting with using DeviceCloud for running our maestro flows. Having a single Master flow means a single 9 cent usage charge to run all of the tests that it contains. --- maestro/Master.yaml | 22 ++++++++++++++++++++++ maestro/config.yaml | 9 +++++++++ 2 files changed, 31 insertions(+) create mode 100644 maestro/Master.yaml create mode 100644 maestro/config.yaml diff --git a/maestro/Master.yaml b/maestro/Master.yaml new file mode 100644 index 000000000..5b931a6dd --- /dev/null +++ b/maestro/Master.yaml @@ -0,0 +1,22 @@ +appId: org.scottishtecharmy.soundscape +# Master flow for Maestro Device Cloud: runs the whole suite as ONE flow to keep +# cost down (Device Cloud bills per flow, so six separate flows cost six times as +# much as this single one). config.yaml restricts the cloud `flows` to just this +# file; the suite flows below are reached via runFlow. +# +# The suite is stateful and ordered (see the docs): Onboarding clears state and +# onboards, and every later flow builds on that, so the order here matches the +# old executionOrder.flowsOrder. Because these are chained with runFlow, the +# master STOPS at the first failing flow - acceptable here since a failure early +# in a stateful suite leaves the later flows without the state they need anyway. +# +# CI (run-maestro-tests.yaml) still runs each flow as a separate emulator flow +# for per-flow reporting; it invokes explicit file paths and does not use this +# master flow or config.yaml. +--- +- runFlow: Onboarding.yaml +- runFlow: HomePage.yaml +- runFlow: LocationDetails.yaml +- runFlow: PlacesNearby.yaml +- runFlow: MarkersAndRoutes.yaml +- runFlow: RouteCreation.yaml diff --git a/maestro/config.yaml b/maestro/config.yaml new file mode 100644 index 000000000..4692f915e --- /dev/null +++ b/maestro/config.yaml @@ -0,0 +1,9 @@ +# Maestro Device Cloud bills per flow, so we run the whole suite as a single +# master flow. Restricting the workspace `flows` to Master.yaml means only that +# one flow is discovered and billed; Master.yaml then invokes each suite flow in +# order via runFlow (which is why the old executionOrder.flowsOrder lives inside +# the master now). The suite flows and the internalFlow subflows stay on disk and +# remain reachable from the master via runFlow - they just aren't run as +# top-level flows here. +flows: + - Master.yaml