added a recursive jobcommand reference for errorhandling

[BobVanB]

<joblist>
  <job>
    ...
    <sequence keepgoing='true' strategy='step-first'>
      <command>
        <description>description</description>
        <errorhandler keepgoingOnSuccess='true'> <!-- This is a job with an extra atribute. -->
          <fileExtension>sh2</fileExtension>
          <script><![CDATA[error]]></script>
          <scriptargs>args2</scriptargs>
          <scriptinterpreter argsquoted='true'>sudo</scriptinterpreter>
        </errorhandler>
        <fileExtension>sh</fileExtension>
        <script><![CDATA[script]]></script>
        <scriptargs>args</scriptargs>
        <scriptinterpreter argsquoted='true'>sudo</scriptinterpreter>
      </command>
    </sequence>
    ...
  </job>
</joblist>

[BobVanB]

I havent tested it, will do that in a few hours, but the xml on the test i wrote is coming out right.
So i dont expect any problems with this, will keep you informed.

[BobVanB]

after i merge my own master with yours XD

[BobVanB]

oh, and i also changed the order of the struct, same as i did with the other one.
This allows me to just export a job and then copy it in the test for marshalXml.

[BobVanB]

And with working code in terraform now.
hashicorp/terraform#8314

[apparentlymart]

@BobVanB, can an ErrorHandler itself have an ErrorHandler? Just wondering since it seems like this structure could potentially support infinite nesting, but I'm not sure if that's intended...

[BobVanB]

@apparentlymart yes, i already got that error on the schema ^^. Fixed that by adding a skipErrorhandler on the schema and removing it.
Probably need to remove continue on error on the command. Because that is only supported in errorhandler.

So I got that coverd.

I dont know why they(rundeck) dont Just add continue on error on each command. Instead of on a sequence. And made the errorhandler also jobsequence. Yes this will adds nesting? Why not ^^ give it a max depth and you got alot better user freadom. As you see the code is the same.

[BobVanB]

Sorry mobile version. Thé previous comment, was for terraform ^^

As you can see, I know about it and I handle it at the software side.

Yes this will add infinite nesting. I did this because I didn't want to copy JobCommand, because it wat 99% the same and if JobCommand changes the error handling also change with it now.

I wil check rundeck tomorrow, to see if they use a different type for error handling.

And all the above. 😊

[BobVanB]

I just checked with the rundeck code:
convertXmlWorkflowToMap
You can see here that the same code for a command is used for the errorhandling.
data.commands.each(fixup)
data.commands.each { if (it.errorhandler) { fixup(it.errorhandler) } }
This is the same with: convertWorkflowMapForBuilder

To be neat, the errorhandler should be removed on the second level (within errorhandling)

[BobVanB]

If i go through the above code and i have already tested it with posting:

  command {
    description = "${file("${path.module}/scripts/service/mongo/hiera/remove/query_description")}"
    errorhandler {
      errorhandler {
        inline_script = "script3"
      }
      inline_script = "script2"
    }
    inline_script = "script1"
  }

i can conclude that rundeck also supports infinite nesting and it will not break if deeper levels are posted. Errorhandler is just being ignored by rundeck.

My choice would be just let it like this and support infinite nesting, its up to the sanity of the user this way.

And i think i know why errorhandler is of the type JobCommand and not JobSequence, i can just call a JobReference and that will contain my sequence....epiphany :D

[BobVanB]

Rundeck is also alowing 'keepgoingOnSuccess' (terraform: contiue_on_error) on the JobCommand in the JobSequence. There is no validation whats so ever on that part. Structual its correct.
Rundeck will only read what it needs. (wrong but he, who am i to judge :D)

[apparentlymart]

Thanks again, @BobVanB, and thanks for taking the time to investigate and explain how this works in Rundeck.