In case of a mistake, Updatecli returns an error similar to

ERROR: the specified sourceid "getLatestJenkinsWeekly" for condition[id] does not exist
ERROR: failed loading pipeline(s)
	* e2e/updatecli.d/success.d/partial/jenkins.yaml:
		* Partial files:
			* e2e/updatecli.d/success.d/partial/_source.yaml
		* Error:
			conditions validation error:
			wrong updatecli configuration

It's not easy to provide better error message since the manifest need to be rendered as a whole before validiting it

I like the idea of automatically loading any _*.yaml file in the current directory. However, a use case that just came to mind is maintaining a collection of partial configs that can be reused when creating new Updatecli pipelines. I can still make this work with the proposed implementation by using symlinks. For example, I might have a partials/ directory containing shared scm.yaml files, and a separate manifests/ directory with pipeline definitions like pipeline1.yaml. Inside manifests/, I could symlink one of the scm.yaml files from partials/ to include it in a specific pipeline.

That said, I think it would offer even greater composability to support a dedicated keyword in the manifest to explicitly declare which files to load. For instance, an imports keyword could accept a list of optional files to include, defaulting to the _*.yaml pattern.

This would allow each pipeline to declare exactly which partial configs it depends on, resulting in a more DRY and modular setup.

I realize this overlaps somewhat with the Updatecli policy feature, which supports storing versioned config fragments in an OCI repository. Still, I believe this approach would be more straightforward for users, as it avoids external dependencies and works with just a Git repository.

Of course, what I'm proposing here could be moved into a separate task. The current PR could be merged as-is since it's a solid first step toward more composable updatecli pipeline definitions.

That said, I think it would offer even greater composability to support a dedicated keyword in the manifest to explicitly declare which files to load. For instance, an imports keyword could accept a list of optional files to include, defaulting to the _*.yaml pattern.

In theory, I agree with you, in practice, I have a chicken-and-egg problem. Because of the golang templating we would first need to render the manifest in order to be sure that the "imports" settings is correct and then we could re-render the manifest a second time with the partial files listed in the import section. I fear that it could lead to confusion

In the current implementation all the files are concatenated together so any YAML file starting with --- will be considered as a different YAML document which may lead to some confusion on a large project.

I just can't see a way to avoid this technical limitation as it's a chicken and egg problem