executeCommand doesn't catch errors when using properties

General Discussion
1

I am trying to use executeCommand with OS specific scripts. A command might be something like:

<changeSet author="ctrezza" id="theid">
            <executeCommand  executable="node.exe"
                timeout="500s"
                    os="Windows 10">
            <arg  value="hello.js"/>
        </executeCommand>
    </changeSet>

I’d like to change the os and executable values to use a property instead:

        <property name="NODE" value="node.exe" />
        <property name="OS" value="Windows 10" />

<changeSet author="ctrezza" id="theid">
            <executeCommand  executable="${NODE}"
                timeout="500s"
                    os="${OS}">
            <arg  value="hello.js"/>
        </executeCommand>
    </changeSet>

I feel like these should be equivalent and avoids the issue of windows version strings where I have an operating specific command to run. It’s important that if these scripts fail, that this failure is captured when the command runs, so that if my hello.js contains:

process.exit(1);

That the update command will catch it. And if I do not use a property, it does indeed catch that error:

Unexpected error running Liquibase: Error executing command: node.exe hello.js returned a code of 1

But I use a property instead, I don’t see any output, and the changeset is recorded as deployed in the database. It should not.

I don’t want to have to hardcode windows versions in the changelog. Is there a way to make this work?

2

Alright, so I figured this out and I’ll just explain so no one else runs into it.

In my example, I used “OS” as an environment variable, but on Windows this is set to “Windows_NT” on my system, because Windows NT will never die, apparently. :upside_down_face: So when this script is run with -logLevel=all you can see that it finds “Windows_NT” as the environment variable, it doesn’t match “Windows 10” which is coming from the java system, and since it doesn’t match, it doesn’t run. And then gets blissfully recorded into the database as done! The solution is to not use OS, but use something other than “OS” as the environment variable, and then it works as expected.