Wait, really? That’s a massive step backwards then, is it not?
Not sure I follow. Per the yaml spec you cannot use anchors across yaml documents. If your use case is not solved by yaml you can enabled and use jsonnet  or use the starlark extension  which gives you the full power of a programming language when defining your pipelines.
Thanks for the prompt replies! Let me rephrase. It seems like a major step backwards because the syntax requires multiple yaml documents to model pipelines thus preventing users from using anchors effectively.
Looking at the older syntax, pipelines were just under a key in one document, so anchors were useful then but now they’re not. Are there some benefits to making each pipeline specification its own yaml doc I’m not seeing?
I’m evaluating enterprise ci solutions for my company to replace Bitbucket — we already have many pipelines in yaml and everyone is familiar with it. It’s going to be hard convincing my team to go for jsonnet or sarlark over yaml.
I recommend posting some real world examples of a yaml in 1.x syntax, and then an example of how you would have modeled the yaml in 0.8 syntax. I think this will help us advise further. I would not suggest that every project adopt starlark or jsonnet … only the subset in your organization that have sufficient complexity that they would need the power of a programming language. In my experience the majority of projects in an organization can use a single pipeline, with conditions as needed , in which case anchors will work just fine. You could fallback to using the 0.8 yaml with Drone 1.x although I am not sure this would be the best approach. Lastly you also have the option to extend the Drone yaml through extensions