Add global state for all tasks/targets

[korney4eg]

Based on ansible, terraform experience I came up with idea of having global state that could consist of some usefull information from all of tasks/targets.

Example state from simplified playbook could look like map that I will show in yaml format:

tasks_state:
  - name: wait
    target: target1
    status: success # this could be some predefined set of statuses, e.g. "success", "failed", "skipped"
    return_values:
      exit_code: 0
      std_out: ''
      std_err: ''
      execution_time: 
      ....
  - name: wait
    target: target2
    status: failed
    return_values:
      exit_code: 1
      std_out: ''
      std_err: 'no disc space left'
      execution_time: 5s
      ....
  - name: copy configuration
     target: target1
    status: success
     return_values:
       changed: false
       sha256: '73267ba...'

So later we can somehow reuse those values like we do it in ansible, but right now we can just print them out.

If you like this idea or you have your own idea of implementation I would like to participate.

[umputun]

I'm not entirely sure what status is. Is it for ignore_error mode only? Because the normal run will terminate the rest of the playbook on the error. Probably for ignore_error it makes some sense but feels like a corner case to me and I don't clearly see the intended use case.

Regarding "global" variables - it is already a thing; see https://github.com/umputun/spot#passing-variables-from-one-script-command-to-another. In your examples, the vars you set are some low-level things like std_out or execution_time. Unless I missing the point, I don't really see the use case for those vars and why passing those values to other tasks/commands is useful.

regarding " can just print them out" - the echo command does exactly this https://github.com/umputun/spot#echo

Just to reiterate the current status of vars: each script command can use export foo=bar and this will "export" foo var to the global space for the rest of the commands. The "bar" value can be runtime value as well, for example export foo=${pwd) will work the way you are expecting. All other commands can use this $bar in any place, which can another script, or copy/delete/whatever parameter.

[korney4eg]

Thanks for quick responce.

Regarding status : you are right, that this would be used mostly for ignore_errors option and color the output.

For good example of return values check out ansible copy module returns, later somehow we can assign one of this values to environment variable. And yes, we still can write everything in shell and export needed values.

If this proposal doesn't suit your product vision, feel free to close it. I'm ok with it. All I wanted - to practice in programming in golang. Will wait for good_first_task label then.

[umputun]

This is an excellent example of why I'm not particularly fond of Ansible; there are simply too many different elements. Personally, I don't understand why anyone would need all this information as a variable for the following command. What exactly is one supposed to do with the checksum, backup_file, or uid/gid in this context? Anyway, I try not to add things to the spot unless there is a clear and justifiable use case for it. The general idea of 'let's add it and figure out later what it's good for' goes pretty much against the basic idea of the spot - to keep things as simple and minimal as possible.

[umputun]

moving to discussions