feat(ci status): keep --live polling through transient pipeline states
What does this MR do?
The glab ci status --live loop only treats pending and running as in-progress statuses. Several other valid GitLab pipeline statuses (created, waiting_for_resource, preparing, scheduled) cause the loop to exit immediately even though the pipeline is on its way to running.
Additionally, when a pipeline is auto-canceled because a rebase triggered a new pipeline, the live loop exits on the stale pipeline instead of following the new one.
This MR:
- Treats
created,waiting_for_resource,preparing,pending,running, andscheduledas in-progress statuses for--live. - On
canceled, re-queries the latest pipeline for the branch — if a newer one exists, switches to it and continues monitoring. If the same pipeline is returned, exits cleanly. - Extracts the status check into a small testable helper (
isLivePollableStatus).
Note on the original bug report: the proposed fix in #7870 (closed) used the spelling cancelled, but the GitLab API value is canceled (one l, per BuildStateValue in client-go). The patch as written would not have matched.
Related
Closes #7870 (closed)
Testing
- Added a table-driven test for
isLivePollableStatuscovering every status defined inBuildStateValueplus unknown/empty inputs. - Added two integration-style tests covering the canceled-supersede flow: one where a newer pipeline replaces the canceled one, and one where the same canceled pipeline is returned (clean exit).
- All existing CI command tests pass.
Author's checklist
- Tests added/updated
- Documentation not affected (no flag changes)
- Linter passes