Prioritise failures when several builds share a light

Status Light can summarise several builds through a custom integration, but one physical display cannot show every result at once. If the latest event always wins, a successful minor job can hide a failure that still needs attention. Keep individual build records and calculate the displayed summary from a deliberate priority rule.

Which builds belong in the summary?

Define the projects, branches or tasks included in the desk view. A broad subscription does not mean every event should affect the lamp. Exclude unrelated activity explicitly so an old experimental run cannot dominate the display for work you are not tracking.

Give each included build a stable identity and distinguish attempts. Keep the source result and freshness for each one. A retry of a failed build should follow a documented rule for superseding the earlier attempt rather than relying on whichever delivery reaches the receiver last.

What should take priority over running work?

Choose whether an unresolved failure should remain visible while other builds continue. If so, state how a failure becomes resolved: a verified replacement result, a change in tracked scope or a separate acknowledgement policy. Merely receiving a new running event should not erase it by accident.

Distinguish an acknowledged failure from a successful build. You may choose to reduce its attention priority after seeing it, but retain the source outcome in the detailed view. Otherwise the summary can become a record of button presses rather than a trustworthy account of the tracked work.

How can the user find the build behind the signal?

Provide a companion list or source link showing the items responsible for the current summary. A red signal without an identifiable task sends the user searching across projects and reduces the usefulness of the physical cue.

Order the detail list using the same policy as the lamp, and show uncertainty when a tracked source has gone stale. An unavailable result should not silently disappear from the aggregate as though that build had succeeded. Decide how incomplete evidence affects the overall summary and document it.

How do you test the aggregation rule?

Use a small controlled set of builds with mixed states. Include an unresolved failure followed by an unrelated success, a retry that genuinely supersedes a failure and a stale source. Check the calculated summary after each transition before sending a device command.

Use only the output controls confirmed for the hardware. The Status Light listing describes the physical unit; useful multi-build behaviour comes from per-task records, explicit priorities and a clear route from the signal to the work that needs attention.