New Build Stages has made it possible to run jobs that depend on each other. However, naturally, dependencies between jobs are not a list but a directed acyclic graph.
This discrepancy has already caused trouble and inconvenience for me: see https://github.com/skvark/opencv-python/pull/228#issuecomment-519477129 where the jobs would run (and any errors detected) much later than they naturally could, leading to a waste of both programmer’s and Travis machine time.
In https://stackoverflow.com/questions/57926758/a-human-readable-textual-representation-of-a-directed-acycling-graph, it was formally shown that a YAML nested list with anchors is an adequate representation of a DAG – and the most human-readable and human-editable one invented so far.
As such, if we convert stages: (or add an alternative clause) to such a data structure, we would obtain all the benefits of the “pipelines” feature that competitors (Azure, Gitlab, Circle) have – without the complex web UI and having to store those settings outside of user codebase!
Tbh, we will probably need a web UI tool – the one that would parse the .yml and show the set of jobs that it would result in.
But we are going to need it anyway for other needs:
- matrix expansion and stages are already making it hard to readily see what a
.ymlwould produce - users are having trouble seeing (as in, have created multiple support tickets asking for help with) when their build is not created due to parsing errors and what in the
.ymlis causing those errors.