An idempotent operation can be performed multiple times without changing the result beyond the initial application. Put more simply, an operation is idempotent if you can repeat it over and over again without causing any unwanted side effect or harm to the system, always producing the same result.

I agree with these, and, that's not what actually happens with MergeCPF.

We have two different options

• CreateNamespace
• ModifyNamespace

But, to make MergeCPF truly follow idempotent, it should be only one like CreateOrModifyNamespace or to make it declarative way just Namespace. Where in this case, I will get what I defined in any case

I have this file

[Actions]
CreateDatabase:Name=DEMO,Directory=demo
ModifyNamespace:Name=DEMO,Globals=DEMO

I have no NameSpace Demo, and after merge, I will get the new Database, But No Namespace at all. And no failure, merge said all good.

Yeah, probably Namespace not a good example, not so variants to change it on the fly, but what about User, I would probably want to change password with the next deploy, or changes Roles. Or CSP Application , and so on. 

In the current state of work, the only correct way is to always define Create and Modify, so, it will always create the desired resources, and Modify, if I would need to update already created previously. This does not look like an obvious way to go, at all.

Right %Installer is still in place, and we have it in some of the templates.

So, what would I like to see in with iris merge

• error code 0, for success
• --dry-run flag, to have an ability to somehow validate the merge process, what will happen if I do merge
• --verbose|-v flag, or by default, and --no-verbose to get the current behavior. Verbose output should show every single change made, similar to %Installer output, including plain changes not covered by [Actions]
• --fail-fast by default, fail on any error that happens, CreateNamespace on existing namespace should fail, and so on.
• --ignore-errors for the current behavior, when some issues are ignored completely. But it still has to log in verbose output.

When I use docker in any project, I expect that any Docker build, will do the job as I expected, or fail-fast. We already have a bunch of templates with docker and zpm. And we have lines like this in Dockerfile

RUN --mount=type=bind,src=.,dst=. \
    iris start IRIS && \
	iris session IRIS < iris.script && \
    iris stop IRIS quietly

So, I expected that I would just add merge there, so I could get what I want

RUN --mount=type=bind,src=.,dst=. \
    iris start IRIS && \
    iris merge IRIS ./merge.cpf && \
	iris session IRIS < iris.script && \
    iris stop IRIS quietly

And what I found, is that even though I use start, session, and stop from the same iris command, always had no issues, and suddenly, merge failed my build, even though the output says, it's a success. I did not expect that the error code would be just a random magic number, while the whole Linux world uses 0 as a success, and even Windows uses 0 as success, but for unknown reasons, InterSystems uses 3 as success in this case, and did not think it's kind of important and worth to at least mention in the Documentation. 

So, I have no idea how you debug the issues, there, probably you can type with no typos, you can't do any mistakes, but people do mistakes, and it should cover these situations, and indicate that you doing something unexpected. 

As soon as iris merge does not return 0, does not have any verbose output, and ignores issues, I strictly do not recommend this in development and in production for sure at all, to anyone. 

Yeah, node-red was my first attempt. And now, I only found n8n somehow, but did not find zapier and make, which looks like a bit better.

And to do it for make will be even more challenging for me, because it requires .Net for plugins, while node-red, n8n, and zapier are with NodeJS