We predict a large number of Cruise projects, which creates unique requirements around visualizing large amounts of data in the Cruise dashboard:

- Tree based view of project status. Assuming a lower case, dash separated, project naming convention, two projects x-y-a and x-y-b, would result in a tree based view similar to: x/ y/ a/ b/

At each nesting level it is possible to see the aggregate status of all children (is ‘x’ healthy? is ‘x-y’ healthy? and so on).

- Templating of Cruise projects. We’re really seeking the abstract class concept. So more than being able to rapidly create new projects we’re interested in making changes to a global template or abstract class that all children would then inherit the benefit from.

Thanks.

+1.

I’d like to add that it should be trivially-possible to set up a clone of a pipeline – use-case would be working on a feature branch. Preferably, this should be possible via the web-interface, and for bonus points should be possible to go to a form, and trigger the branch to happen in source-control and have the pipeline wired up – essentially, a “create clone for branch” button/form/mechanism.

I am painfully aware that we need to do something in the template / inheritance space. But frankly I don’t really like any of the solutions out there.

@nsikha, to some extent the pipeline metaphor gives you this—stages roll up information about the jobs they contain, and pipelines provide a way of visualising and controlling many stages composed of many jobs. However, your options if you have many pipelines are limited. I am not sure I like tree-based categorisation, because think how many levels you’d need to get through to find what’s going on at the job level. Hierarchies are also hard to maintain and inflexible (think about components shared between several projects). My preference is to use tagging and good search functionality instead.

In order to work out the correct implementation, we need to think about the use cases. One (important) use case is branching, as you point out Pete. What you might want to be able to do is specify a different (set of) materials, but keep the rest of the pipeline the same. Things get complicated once you want to tweak configurations between pipelines.

Another use case is having a job that needs to run on multiple environments. In this case you’d want to change the resources that a job requires, but keep the rest of the job definition the same.

There are other use cases out there: please contribute, the more you contribute, the better the solution will be.

Finding one mechanism that supports all the use cases while not making configuration horribly complicated is going to be hard, and as I say I don’t really like any of the solutions out there. So anybody have any crazy ideas?

Jez.