Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define output of an async task (started with await: false) #1004

Open
matthias-pichler opened this issue Aug 30, 2024 · 3 comments
Open

Define output of an async task (started with await: false) #1004

matthias-pichler opened this issue Aug 30, 2024 · 3 comments
Assignees
Labels
area: spec Changes in the Specification change: documentation Improvements or additions to documentation. It won't impact a version change. change: feature New feature or request. Impacts in a minor version change
Milestone

Comments

@matthias-pichler
Copy link
Collaborator

matthias-pichler commented Aug 30, 2024

What would you like to be added:

Something I missed in the PR #995 that introduced the await property is to define what the (raw) output of a task with await: false is.

We should document the output of a run task in general. Because what is the output of a run.container task?

Why is this needed:

Dicjment the output of an async task

@matthias-pichler matthias-pichler added the change: documentation Improvements or additions to documentation. It won't impact a version change. label Aug 30, 2024
@matthias-pichler matthias-pichler added this to the v1.0.0 milestone Aug 30, 2024
@cdavernas cdavernas changed the title Define output of an async task (started with await: false) Define output of an async task (started with await: false) Aug 30, 2024
@cdavernas
Copy link
Member

cdavernas commented Aug 30, 2024

As far as I understand it, an async task should output its transformed input. IMHO, runtimes should ignore output transformations and export, as async task should not be able to output.

As for "standard" run task output, it's a discussion we had in the past with @ricardozanini and @JBBianchi. If I remember well, it should be the task's stdout, but we should probably provide a flag that indicates whether or not to deserialize it, in case it's JSON or YAML encoded. We should probably open another issue to address that specific concern, which might also be related to #998

@matthias-pichler
Copy link
Collaborator Author

matthias-pichler commented Sep 3, 2024

As for "standard" run task output, it's a discussion we had in the past with @ricardozanini and @JBBianchi. If I remember well, it should be the task's stdout, but we should probably provide a flag that indicates whether or not to deserialize it, in case it's JSON or YAML encoded. We should probably open another issue to address that specific concern, which might also be related to #998

I also thought about returning stdout, maybe it might even be worth it to return an object

{
  "stdout": "...",
  "stderr":  "..."
}

since some tools print a lot to stderr as well and it might be needed to detect errors. But in other cases some containers might be very noise and so authors might want to discard the output. Maybe the way to go is an output property similar to call: http?

document: {}
do:
  - runContainer:
      run:
        container:
          image: alpine:latest
          output: "stdout" # "stdout" | "stderr" | "all" | "none"

I am unsure if we should handle JSON/YAML deserialization since jq offers @json @html, ... see jq manual

Do we have to introduce the same thing for run.shell?

@cdavernas
Copy link
Member

cdavernas commented Sep 3, 2024

@matthias-pichler Great idea! And yes, I would extend your proposal to all processes, not just shell!

@cdavernas cdavernas added change: feature New feature or request. Impacts in a minor version change area: spec Changes in the Specification labels Sep 6, 2024
@cdavernas cdavernas modified the milestones: v1.0.0-alpha3, v1.0.0 Oct 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: spec Changes in the Specification change: documentation Improvements or additions to documentation. It won't impact a version change. change: feature New feature or request. Impacts in a minor version change
Projects
Status: Todo
Development

No branches or pull requests

2 participants