Github action for reserving multiple machines with multi-device agent

[marosg42]

GH action to reserve one machine works great.
However there is also multi device agent which allows to reserve several machines at once and they behave as a group, either all are reserved or job fails.
Input for the action will be valid Testflinger job in yaml file.
Output will be two lists

• list of job ids of reservation jobs (so that they can be cancelled when machines are not needed before timeout)
• list of IPs of reserved machines

To avoid complexity action can require that job always contains reservation data and never test or other than provisioning data

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/CERTTF-457.

This message was autogenerated

[mz2]

@marosg42 could you describe the output you'd expect from testflinger-cli exactly, please?

[marosg42]

Similar to single job action which has

outputs:
  id:
    description: 'The ID of the submitted job'
    value: ${{ steps.submit.outputs.id }}
  device-ip:
    description: 'The IP of the reserved device (if applicable)'
    value: ${{ steps.track-reservation.outputs.ip }}

Action for multiple devices will output JSON list of job ids and a JSON list of device-ips.

[boukeas]

@marosg42 Please take a look at this draft PR. It comes with a test example on how to use the new action and shows what the output looks like.

On the latter: the structure of the output is what I'd most like some feedback on: in your original message you described the output as two lists containing job IDs and machine IPs whereas I opted for a JSON string that maps job IDs to machine IPs. Let me know if that is convenient for you to use in your workflows or if you'd like some variation of it -- it's really easy to re-structure the output, I think the main point is the action is able to retrieve the required data.

Also, note that this action is only for polling the parent multi-device job and retrieving the data of the child jobs. It is not for submitting the job, as the original request describes, since that can be accomplished using the existing submit action.