Manually Trigger the Next Rollout Group

This new rollout feature gives you more flexibility in controlling the execution of your rollout groups. Typically, the cascaded execution of rollout groups is controlled by the so-called "trigger threshold". The trigger threshold specifies a percentage of target devices which have finished their installation of the assigned firmware update. When the trigger threshold is exceeded, the next rollout group will be executed.

There are cases, however, when the trigger threshold of a rollout group is never met, for example, if too many target devices are offline. As a consequence, the execution of your rollout, in particular the execution of the remaining rollout groups, might be stuck. To overcome this state, you can now manually trigger the next rollout group, without waiting for the trigger threshold to be reached. The new feature is offered as part of the Management API and Management UI.

For more information see Rollout view>Manual triggering of next group.

New Resource Collection "/rest/v1/actions" in Management API

This new Management API feature provides read-only access to the collection of deployment actions via the context path "/rest/v1/actions". Furthermore, it allows you to filter this collection in a very flexible way by defining FIQL queries (request parameter 'q'). For example, you can define the following queries:

• Find all actions that match a certain action status (e.g. downloaded, finished, error, scheduled etc.).

• Find all actions that were spawned by a certain rollout.

• Find all actions that failed with a certain status code.

• Find all actions that refer to a certain distribution set.

So far, the collection of deployment actions could only be accessed for a specific target device ("action history"). With this new API, you can retrieve the data that is relevant for your specific scenario and feed it into your own custom UIs (e.g. dashboards) to monitor and troubleshoot your firmware updates.
Find more details in our API documentation.

1.18.3