Running and watching

How execution starts

A workspace has no separate “Run” button: it is created already running, at the moment you confirm the original operation (applying stand settings, a release, a build, a platform data refresh). Which operation produces which workspace is listed under Workspaces.

After you start a release its graph opens immediately. In every other case you go to the graph yourself: through the Workspaces menu entry or, for a build, with the Workspace button in the build history row.

How to read node states

Both each step and the operation as a whole have a state. A step has four:

State	What it means
Queued (grey)	The step is waiting its turn — either nothing has reached it yet, or it is waiting for previous steps to finish
Running (blue)	The step is running right now
Completed (green)	The step finished successfully
Failed (red)	The step ended with an error

The overall state of the operation: Pending — nothing has started yet, Running — work is in progress, Completed — every step is through, Failed — at least one step failed.

A long “Running” is normal

A build step stays in the “Running” state for as long as the build takes in the external system: PDM polls it regularly and waits for the result. Several minutes on one node is expected, not a hang.

What updates on its own

There is no need to reload the page: node states, the overall operation state and the contents of an open step window — logs included — are filled in as execution proceeds.

Where to find results and errors

Investigating is simple: find the failed node — that is where everything stopped — and open its card. The error text and links to external systems (the build pipeline, for instance) are on the Overview tab, the line-by-line output is on the Logs tab, and the step's input and output are on the Data tab. See Graph editor for more about the card.

The result of a successful operation shows up in more than green nodes: applied settings appear on the stand's “Services” tab, the built image in the build history, the rolled-out release in the release history.

A failed step stops its branch

Nodes after the failed one stay in the “Queued” state — they never ran. That matters when you are investigating: “not done” here means “never reached”, not “done unsuccessfully”.

Can it be restarted

An existing workspace cannot be restarted. If the operation failed, fix the cause and start it again the same way you did the first time: mark the changes again and press Deploy changes, assemble the release again, and so on. A new workspace appears; the old one stays in the list as history.

Builds are the exception: in the history on the “CI Builds” page a failed build has a Retry button that runs it again with the same parameters (and creates a new workspace).

How to share the progress of an operation

The Share button creates a link to this operation. Such a link grants access to that one operation — it opens even for someone whose regular permissions would not show it. That is handy for attaching to a ticket or sending to a colleague, but keep in mind: everything visible on the page, step details and logs included, becomes available to whoever holds the link.

What's next

• Graph editor — more about nodes, connections and the step card.
• Stand configuration — how to prepare and apply changes on a stand.
• Rollout and outcome — the largest operation and its graph.