Activity details
The activity details screen is a critical component of OpsChain, providing in-depth information about specific changes and workflow runs. This guide will help you navigate these details screens, understand the execution progress of changes and workflows, and manage them effectively.
Accessing the activity details screen
To view the details of a particular change or workflow run:
- Access the list of activity by selecting the activity option in the left sidebar.
- Click on a specific activity row in the table to open the details screen.
Understanding the activity details screen
The activity details screen is divided into several sections, providing a comprehensive overview of the activity's lifecycle.
While a change or workflow run is open, the browser tab's title and icon also reflect its current status, so you can keep track of progress even when working in another tab.
Header information
From left to right:
| Information | Description |
|---|---|
| Status icon | An icon representing the activity's status. |
| Action name | The name of the action being executed. |
| Started by | The name of the user that initiated the action. |
| Site | The site that the activity is running on. |
| Site | The OpsChain site the change ran at and reads - until the change starts. |
| Status | The current status of the activity. |
| Blocked by queue | If the activity is blocked by other items in the queue, a dropdown will be shown with the name of the activities that are blocking it. |
| Timing information | Displays the relevant timing information for the activity, including the creation date and all the status transitions such as when the activity started running, when it has finished, etc. |
| Git reference | Shows the Git reference associated with the activity, including the remote, revision, and the SHA it resolved to. If the activity is for a templated asset, it will show the template version name used in the change. |
| Ran as part of change | Shown when the change was created by another change's action, through the API. Links to the change that created it. |
| Ran as part of workflow | Shown when the activity ran as a step of a workflow run. Links to that run. When a retried workflow run reused the change or child workflow run, this reads Part of workflow runs and lists every run it belongs to, with the run it actually ran in highlighted. |
| Asset action | Shown for a change on an asset that started partway through an action. Links to that action on the asset's actions tab. |
Change activity tabs
For changes, available tabs include:
- the change's step tree
- the change's swim lane
- the change's logs
- the change's properties
- the change's settings
- the change's MintModel, if any was used
- the change's metadata, if any was added
- the change's artefacts
- the change's audit history
The step tree, swim lane and change logs tabs are three different views of the same activity. The step tree opens by default; use the view settings menu (the cog next to the tabs) to choose which view opens first when you view a change or workflow run - your choice is remembered in the browser.
Swim lane
The swim lane view groups the activity's steps into a handful of columns - or lanes - by their current status, giving you an at-a-glance summary of what is up next, what is waiting, what is running and what has finished. The step tree opens first by default; select the swim lane tab, or make it your default view, to use it.
| Lane | Contains |
|---|---|
| Up next | Steps that are initializing, pending or queued. |
| Waiting | Steps waiting for manual continuation or approval. |
| Running | Steps that are currently executing. |
| Incomplete | Steps that ended in error, or were cancelled, aborted, rejected or removed. |
| Completed | Steps that finished successfully, or were skipped, approved or continued. |
Within a lane, steps are grouped under their parent (wrapper) step, and each lane has its own status filter so you can narrow a busy lane down to a particular status. A search box lets you find a step by its name or action across every lane. The same step actions available in the step tree - opening logs, continuing, approving and so on - are available from each card.
Use the show/hide wrapper steps toggle to include or exclude wrapper steps (steps that exist only to group their children). This preference is remembered separately for changes and workflow runs.
Step tree
The step tree tab visualises the following:
- Sequence and hierarchy of steps involved in the change or workflow run
- Each step is represented as a node within the tree, with the execution progress being indicated via the node's colour
- Real time execution progress is shown next to each step, indicating the time each step took or has been taking to execute.
The arrangement and execution flow of steps are visually depicted from top to bottom and left to right. OpsChain initiates with the foremost step, navigating through to any sub-steps (children) in a left-to-right manner before moving to subsequent steps positioned below (top-down).
Step execution strategy
The step tree represents all the steps of the change or workflow run and they are organised based on the execution strategy that was defined for the action. Steps can be executed sequentially or in parallel.
| Execution mode | Description |
|---|---|
| Sequential | Steps follow a linear progression, where each step commences only after the preceding step has concluded. |
| Parallel | Steps occur concurrently, without needing the step to be completed before another begins. |
When a step's children run in sequential mode, its children will be connected by a single arrow line, top to bottom. When a step's children run in parallel mode, its children will be connected by parallel arrow lines.
The execution strategy for an action is fixed and determined by the author of the action. Users cannot alter this strategy from sequential to parallel or vice versa. This design choice ensures consistency and reliability in the execution of changes and workflow runs.
By default, all steps of a change run inside the same isolated container. You can configure a change to run each step in its own isolated container by enabling the pod_per_change_step setting on the project, environment or asset.
Behaviour when a child step fails
The execution strategy also determines how OpsChain handles failures among sibling steps:
- Sequential: OpsChain terminates the change at the completion of the failed child step and any remaining sibling steps will not run.
- Parallel: OpsChain allows all siblings of the failed child step to complete and then terminates the change.
The change status will transition to error when OpsChain terminates the change. See behaviour when a child step fails for the underlying concept.
Step lifecycle
Steps transition between status as they execute. The table below lists the statuses shown in the GUI; see the change and step lifecycle reference for the underlying transitions.
| Status | Description |
|---|---|
| Initializing | When a change or workflow run is created, its state is set to initializing whilst the Git commit is being validated. |
| Pending | A change or workflow run remains in the pending status while waiting for any existing activity in the same environment to finish. A step remains pending until its prerequisites are complete. |
| Aborted | If a step fails or is cancelled, any steps in the same change or workflow run that are still pending will be set to the aborted state. |
| Queued | When a step starts executing, it enters the queued state. Steps stay queued while waiting for an OpsChain worker to start executing them (e.g. if all workers are already busy). |
| Running | Whilst a step is actively executing, it is in the running state. |
| Error | If the step fails, it transitions to the error state. |
| Success | If the step succeeds, it transitions to the success state. |
| Skipped | If the step is skipped either because it was successfully run previously or was marked for skipping during a change retry. |
| Removed | If the step is removed on another action's execution, it is marked as removed. |
When a change or workflow includes wait steps or approval steps, the following additional statuses are available:
| Status | Description |
|---|---|
| Waiting for manual continuation | The step requires a user to manually continue the step, using the continue option in the step's "triple dot" menu. |
| Waiting for approval | The step requires approval from a user or member of the appropriate LDAP group to continue the change/workflow. The step's "triple dot" menu provides approve and reject options for the approver. |
| Rejected | An approver rejected the step rather than approving it. The step and any steps beneath it are aborted. A workflow run reports rejected when any of its steps was rejected. A change reports rejected when the step rejected was its own approval step — rejecting an approval step further down the tree fails that step's parent, so the change ends in error. |
By default, OpsChain allows multiple changes to execute for a given project, environment or asset, but only one with the same action name. This reduces the risk of concurrent changes interfering with each other's properties updates. If your actions can safely run concurrently, you can relax this restriction via the allow parallel runs of the same change setting.
Filtering steps by status
On the left side of the step tree, you can filter the steps by their respective statuses. Use the forward and backward buttons to navigate through the steps that match the selected status.
Navigating the step tree view
Drag the background to pan the tree, and scroll to move through it. The total number of steps in the tree is shown alongside the controls.
The controls on the right of the step tree are:
- Search: Search the tree by step name, action or status - type
errorto find the steps that failed. Use the forward and backward buttons - or Enter and Shift+Enter - to move between matches. - Zoom in / zoom out: Zoom the tree in or out.
- Fit to view: Size the tree to fit entirely on screen.
- Fit to width: Size the tree to the width of the screen.
- Toggle minimap: Show or hide the minimap. The minimap gives you the shape of a large tree at a glance, and dragging within it moves the view.
Expand / collapse, at the top left, controls how much of the tree is drawn. Expand all and Collapse all work on the whole tree, and Show levels draws a chosen number of levels and collapses everything below them - useful for finding your way around a deep tree before opening the branch you want.
The same view, controls and search are used for the workflow run tree, the workflow editor's tree preview and an asset's action tree.
Change logs
The change logs tab contains detailed logs related to a change. Access this tab to review comprehensive log information that can help in troubleshooting and understanding the change's impact.
You can toggle the System logs option to show or hide OpsChain-specific logs, such as image building, etc.
Step logs
To view the log for a specific step, click on the icon to the right of the step name. This will then display the step logs for that particular step and its children. You can disable children logs by toggling the Include child logs checkbox. You can also toggle the Status logs option to show or hide the pod status logs for that step.
Where the step stored any artefacts, Artefacts published by this step lists them, each with a download button. Where it loaded any, Artefacts loaded by this step lists each version it loaded, with when that version was created and when the step loaded it. A version the step loaded more than once is listed once per load.
Show properties opens a panel beside the log holding the properties that step ran with. Pick Initial step properties or Final step properties to see them as they were before and after the step, and narrow the converge from the sources panel as you would on the properties tab. The sources panel starts collapsed here, because it shares the dialog's width with the log - expand it from the rail on the right.
Metadata
The metadata tab displays the metadata that the change ran with.
Properties
The properties tab displays all properties that the change ran with, converged from its parent project, environment, asset and Git repository. This tab also allows you to compare the properties between all its stages during the change's lifecycle, allowing you to see how each step modified the properties.
The sources panel behaves as it does on a node's inherited properties. Show sources annotates each property with where it came from, and unticking a layer converges the change's properties again without it.
A Change layer sits alongside the node layers, holding the property overrides the change was started with. Untick it to see what the change would have run with had no overrides been supplied. When comparing two stages, each side of the comparison is narrowed on its own, and Swap sides exchanges the two stages along with their excluded layers. The comparison is coloured as described under comparing versions.
Read more about properties in the properties concept page.
Settings
The settings tab displays the settings overrides that the change ran with, converged from its parent project, environment and asset. You can read more about settings in the settings concept page.
MintModel
The MintModel tab displays the MintModel that was used to run the change. You can read more about MintModel changes in the MintModel asset templates guide.
Artefacts
The artefacts tab has two views, switched with the buttons above the list. Each button shows how many rows its view holds.
- Published (the default) lists the artefacts the change's steps stored, with the step that stored each one, its code, file name, size and labels, and when it was stored. The tab heading shows how many there are.
- Loaded lists every artefact version the change's steps loaded, with the step that loaded it, its code, file name, size and labels, when that version was created, and when it was loaded. This is the record of exactly what the change used. Every load is listed, so a version loaded twice appears twice. Loads made with the
artefactresource types are listed too.
In either view, select an artefact's code to open its versions page. The list loads more rows as you scroll.
Select the download button on a row to save the artefact's file. The file is streamed straight to disk by the browser, so a large artefact can be downloaded without holding it in the page. A version that retention has purged is still listed, but its download button is disabled.
Audit history
The audit history tab shows the events raised for the change, including those raised by any of its steps, so you can review everything that happened during the change from one place. It uses the same table and filters as the node and global audit history screens, scoped to this change.
Managing changes
Depending on the status of the change, you will see either an approve, reject, cancel, pause, resume, retry, or watch button.
| Button | Description |
|---|---|
| Approve/reject | Visible when a change requires human approval before it runs. |
| Cancel | Visible when a change is currently running. Clicking this will halt the execution of the change. |
| Pause/resume | Pause is visible while a change is running, and Resume once it has been paused. Either asks for an optional reason. See pausing and resuming a change. |
| Retry | Shown if a change has failed, allowing you to attempt to re-execute the change. |
| Watch (bell) | Visible while a change or workflow run is active. Click to receive a browser desktop notification when the run completes. See browser notifications for setup details. |
The approve, reject, cancel, pause and resume buttons require permission to execute the change's action.
If a change is cancelled, all finalised steps (i.e. in the success or error state) remain in their existing state, and all pending, queued, or running steps are transitioned to the aborted state. There is no rollback of any kind; steps that have not yet started will not start, and steps that are in progress are stopped immediately.
Pausing and resuming a change
Pausing lets the steps that are already running or queued finish, but starts no further steps until the change is resumed, when it carries on from where it stopped. While a change is paused its status carries a Pausing marker, which becomes Paused once everything that was running has finished. Hover over the marker to see who paused the change and when. The same marker is shown on the activity table, and workflow runs are paused and resumed the same way.
See pausing and resuming a change for the full behaviour.
Retrying a change
When you retry a change, OpsChain duplicates the existing change as a new change and starts it from where the previous attempt ended. A dialog is presented with all the steps in a hierarchical order allowing you to mark steps to skip during a retry. You can only skip the ones that have failed or have not run yet. The retry uses the resolved Git SHA stored with the original change, and the logs from the original change remain on the original change's details page.
See retrying changes for the full set of caveats - including which steps are rerun and when you should instead create a new change.
Repeating a change
When you repeat a change, OpsChain starts a fresh change using the same properties, settings and Git revision. When repeating a change for an asset, the new change will use the asset's current template version. Whether the change continued its wait steps automatically and whether it was built without cache are carried over into the repeat dialog, where you can adjust them before running.
Downloading a support bundle
When you need to raise a change with LimePoint support, download its support bundle: a zip holding the change and its step tree, its logs, the properties and settings it ran with, its template version and MintModel, and the OpsChain and GUI versions. Each section is collected with your own access, so the bundle holds only what you are permitted to see, and a section that cannot be collected is listed in the bundle's SUMMARY.md rather than stopping the download.
Click the Download support bundle button (a medical case icon) beside the change header's collapse toggle. By default the bundle holds the change log and the logs of the failed steps, keeping the newest 2000 lines of each, and shows times in your browser's time zone.
To change that, open the button's dropdown and select Support bundle options…:
| Option | Description |
|---|---|
| Step logs | Failed steps, All steps, or No step logs to include only the change log. |
| Lines per log | How many of the newest lines to keep from each log. 0 keeps them all. |
| Show summary times in UTC rather than | Tick to show the times in the bundle's SUMMARY.md in UTC rather than your local time zone. |
The button shows how much has been downloaded while the bundle is built. A bundle with every line of a large change's logs can take several minutes. The CLI's support bundle command downloads the same bundle.
Browser notifications
OpsChain can show a browser desktop notification when a watched change or workflow run completes, so you can navigate away and be alerted without checking the page.
To set up browser notifications:
- Open the user menu (top right) and select notification preferences.
- In the browser notifications section, enable the toggle and click request permission to grant the browser the required permission.
Once enabled, a bell icon appears in the actions bar of any active change or workflow run. Click it to start watching that run — the bell turns highlighted to confirm. Click again to stop watching. When the run completes, a notification pops up with a link back to the details page.
Enable the auto-watch active runs option in Notification preferences to automatically watch every active change or workflow run you open, without needing to click the bell each time.
- Tab must stay open. Notifications are driven by polling in the browser tab. Closing the browser or all OpsChain tabs stops the watcher — there is no background service that can deliver notifications when no tab is open.
- Per-browser, per-device. The watch list and settings are stored in browser local storage and are not synced across devices or browsers. You need to enable the feature separately in each browser you use.
- Browser permission is required. If you dismiss the permission prompt or your browser is set to block notifications, you must re-enable it in your browser's site settings — OpsChain cannot prompt you again automatically once permission has been denied.
- OS-level do-not-disturb. Your operating system's focus assist or do-not-disturb mode may suppress browser notifications regardless of browser settings.
- Multiple tabs deduplicated. If you have the same run open in more than one tab, only one notification fires. OpsChain coordinates across tabs automatically.
Workflow run details
For a workflow run, the swim lane and step tree are shown in the same style as for a change, and the step tree is shown in the same style as the change step tree.
A workflow run also has an Audit history tab, listing the events raised by the run, its steps, and the changes it started and their steps. It uses the same table and filters as the change audit history tab, scoped to the run.