This message was deleted.

you're right, both are valid use cases 🙂 it makes sense to organize in dev/prod with multiple env.yaml. that section explains how the env.yaml resolving logic works. if you have a

pipeline.yaml

then it looks for an

env.yaml

, if you have a

pipeline.something.yaml

, it looks for an

env.something.yaml

but it falls back to the

env.yaml

- i agree the training/serving isn't a great example, because training and serving are likely to need more less the same parameters. this example use case applies when you have two pipelines with not so much overlap

OK, thanks. Yeah I can imagine cases where you might want to split it up by pipeline stage. But to me it seems like the environment use case is going to be more typical -- especially since the training stage and the serving stage are presumably going to use the same model store. So from a documentation point of view it seems clearer to prioritize that use case over the per-stage use case. Anyway take it as a data point from one user.

yep! this "shared env.yaml" has come up a few times now 🙂 we'll add it to our sprint for next week. ofc, PRs always welcome!