Feature Request: multiple/reusable configuration files

[gionn]

Is your feature request related to a problem?

Let's say I want to update a bunch of repositories using updatecli, each of them would always have different targets (ansible, helm, docker-compose, etc), but they are probably going to share the same scms and sources since they refers to the same application/product.

AFAIK I am limited to one file per pipeline and I need to repeat scms and sources everytime.

Solution you'd like

Ideally I would like to chain multiple configuration files that get merged into a single one, e.g.

updatecli apply --config updatecli_config_base.yml --config updatecli_config_override.yml --values updatecli_values.yml

Alternatives you've considered

Use an intermediate tool to generate the final yaml to use

Anything else?

No response

[olblak]

I agree, in the current state, having to repeat to the scm block is problematic.
There is a similar issue raise #430

Ideally something I would like to find some time to work on would be #716
Which would reduce the need to specify scm block for the local git repository

[olblak]

The second approach is more likely to be work on as it would solve other limitation around the scm block

[olblak]

while looking at this issue, I am wondering if it's not the best way to handle this problem.

I recently fixed the value files so I could re-apply the same technique here even thought the manifest from a directory could make things a bit more difficult.

[olblak]

I think once Masterminds/sprig#360 is available.
We should be able to leverage templating such as

sources:
  default:
    {{ toYaml .sources.default }}

If need, I may add the function to Updatecli
https://github.com/helm/helm/blob/37cc2fa5cefb7f5bb97905b09a2a19b8c05c989f/pkg/engine/funcs.go

[gionn]

yeah indeed, after #1403 an user could provide multiple values files and each can contains a fragment to be rendered as part of the main config/template

[olblak]

@gionn I just added two pullrequests which IMHO would solve the current problem, similarly to how Helm does it

My concerns are the same ones than when I started working on Updatecli, this would allow to write complex manifest that until will be harder to maintain