Fixes #37320 - Set IDs on outputs

[adamruzicka]

Requires:

• Fixes #37319 - Allow setting IDs for outputs smart_proxy_dynflow#135

TODO:

• bump dependency on sp-dynflow

[adamruzicka]

This should be ready once smart_proxy_dynflow-0.9.4 goes out.

[Copilot]

Pull Request Overview

This PR aims to resolve issue #37320 by setting IDs on outputs. Key changes include:

• Bumping the dependency on sp-dynflow in the gemspec.
• Propagating id and timestamp parameters to output publishing calls in the ansible runner.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
smart_proxy_ansible.gemspec	Updated the runtime dependency constraint for smart_proxy_dynflow to require a minimum version.
lib/smart_proxy_ansible/runner/ansible_runner.rb	Added id and timestamp parameters in methods handling host events and broadcast data.

Comments suppressed due to low confidence (1)

lib/smart_proxy_ansible/runner/ansible_runner.rb:132

• [nitpick] Consider adding unit tests to verify that the 'id' and 'timestamp' parameters are correctly propagated through the publish_data_for and broadcast_data methods.

        publish_data_for(hostname, event['stdout'] + "\n", 'stdout', id: event['uuid'], timestamp: event['created']) if event['stdout']

[adamlazik1]

full ISO timestamp is converted to 2025.0 by smart_proxy_dynflow calling timestamp.to_f. Is that expected?

[adamlazik1]

LGTM other than the comment above. But that would be solved in a different repo anyway.

[adamruzicka]

Is that expected?

It's been a while since I put this together, but no, that doesn't sound right.

But that would be solved in a different repo anyway.

Eh, not really. It expects a time instance, not a string.

[adamruzicka]

@adamlazik1 changed, could you please look once more?

[adamlazik1]

Right now I am getting "timestamp"=>1766156561.3115878 on the foreman side, which would be equivalent to Time.now.to_f, so it looks like it works as intended.

Also, I don't know how much this matters, probably not a lot, but should warning be thrown if parse_timestamp intercepts an exception instead of passing a new timestamp based on Time.now?

[adamruzicka]

Also, I don't know how much this matters, probably not a lot, but should warning be thrown if parse_timestamp intercepts an exception instead of passing a new timestamp based on Time.now?

Probably not a whole lot, but added anyway

[adamlazik1]

LGTM

[adamlazik1]

Thanks @adamruzicka!