The CI/CD pipelines I had to deal with were more like streaming jobs. They had stages and each stage executed on its own schedule and triggers. It wasn’t just a sequence of steps which is always executed for every commit. For example, a pipeline could have:
- Build stage which ran verification build and unit tests for each new commit
- Integration tests that ran once per hour for all commits accumulated during this hour
- NIghtly performance regression tests that executed for all commits since the last run
- Release stage that was triggered manually and on average executed once per two weeks.
It is not possible to model such a pipeline as a simple sequence of steps. So we modeled it as always running child workflow per stage with each individual stage run as a child workflow. For the above example, it would have one top-level workflow and 4 children. And each build, test, or release instance would be a child workflow (with the stage being a parent) execution.
Any workflow can be queried for its current state at any time. So visibility is not a problem.