Changing Pipeline YAML Schema

Having jobs and resources as top-level keys in the pipeline schema means that it’s very hard to adhere to package cohesion principles - in particular “things that change together, stay together.”

I dunno about you folks, but when working with complex pipelines, flitting between the resources block and the jobs block is a source of frustration and error. This can be mitigated through the use of YAML anchors, but that introduces a layer of indirection.

Would anyone else see benefit in being able to define logically-related resources, jobs, and resources types together?

2 Likes

I could see some benefits, but it really would depend on “how” you intend to achieve the cohesion principle. Do you have an example yaml scheme?

Personally I rather like the current “separation of concerns” style schema, but there are cases where I have to work around it with Yaml style hacks. So there might be a middle ground…