-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Make it possible to extract results from a container's stdout #2925
Comments
OR another idea that might be much better: If a step could access the stdout of the previous step, then I could easily have a second container in my task that parses out the project name, e.g. something like: apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: boskos-acquire
spec:
steps:
- name: boskosctl
image: gcr.io/k8s-staging-boskos/boskosctl@sha256:a7fc984732c5dd0b4e0fe0a92e2730fa4b6bddecd0f6f6c7c6b5501abe4ab105
args:
- "acquire"
- "--server-url=http://boskos.test-pods.svc.cluster.local"
- "--owner-name=christie-test-boskos"
- "--type=gke-project"
- "--state=free"
- "--target-state=busy"
- name: grab-project-id
image: ubuntu
script: |
echo $(steps.boskosctl.stdout) | jq -r ".name" > /tekton/results/project-id
results:
- name: project-id
description: The name of the project acquired A couple of ways this could work:
|
If
This could be done the other way, aka specify for a step that you want the output to be written to a file so that any next step in that task can do whatever with it. Using variable interpolation to guess that would work too, I wonder which approach is the saner, but I lean towards having an explicit way to say "I want the output of this step to be written somewhere" (especially because this doesn't have any implication on the variable interpolation part, it's simple for the user to understand what it is doing).
I would definitely not want that 🙃 This could create a lot of I/O for all task/step execution where it will not be needed. |
I think we also need to gauge the number of cases where this is required and where it would be a pain to do it otherwise (aka when you don't have a wait to write to a file in the image, using a shell or something else). |
Oh yeah, that's a good point, I guess it is a convention for a lot of tools to output to a file based on a flag 🤔 However I'd say it's even more common for tools to output to stdout and call it a day - aka relying on "text streams" so it feels to me like there are probably a lot of cases where capturing stdout will be the only way to get the output.
Maybe a way we could adjust this would be to allow steps to opt into this. Personally the option I currently like the best is to go the variable substitution route :D |
I actually really really like both the initial proposal - After reading through I think there might also be an alternative for accessing the stdout inspired by the |
One more possible ux: https://docs.github.com/en/actions/reference/workflow-commands-for-github-actions#setting-an-output-parameter GitHub actions does something similar with special tokens in the output to denote a value. Probably a bit simpler than json, unless your tool already happens to output things in json. So maybe a tossup? |
Rotten issues close after 30d of inactivity. /close Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
@tekton-robot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/remove-lifecycle rotten |
/reopen |
@chhsia0: You can't reopen an issue/PR unless you authored it or you are a collaborator. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@bobcatfish Would you mind reopening this issue? |
/remove-lifecycle rotten |
@vdemeester: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
maybe you can do sth like:
|
If a tool works with output streams, it's really important that it does not pollute such stream, mixing output, logs and stderr al together, because doing renders the stream un-parsable at best. From a Tekton POV I think it would be nice to provide an option to capture stdout to file, if the tool does not support it via a flag. The output is already captured by the pod, but AFAIU that includes stdout and stderr mixed together, so it may not provide what we need; we could write stdout to a file, but I would make that an opt-in, because other steps may write long logs to stdout, and we don't necessarily want to capture that on an extra file.
|
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
/remove-lifecycle rotten Also quite interested in these features. |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
That's why I think the issue should stay open. /remove-lifecycle stale |
For containers without a shell, that also lack an option to output to a file, this would be incredibly appreciated! We can't run certain tools in Tekton due to the lack of this feature (without hacky workarounds, of course) |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
Rotten issues close after 30d of inactivity. /close Send feedback to tektoncd/plumbing. |
@tekton-robot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Implements Option 1 of [TEP-0011](https://github.com/tektoncd/community/blob/master/teps/0011-redirecting-step-output-streams.md) Resurrects [#3103](#3103) Closes [#2925](#2925) Signed-off-by: Brad Beck <bradley.beck@gmail.com>
Feature request
I'd like to be able to create a Task which provides results with come from the output of a container, without having to capture that input and parse it in my Task.
Initially we could do this only when output is json formatted maybe?
For example do something like this:
The
fromStep
above would express the jsonpath to the desired value to use as the result, which is expected to be in the stdout of the command.Use case
I'm working on a boskos Task as part of the catalog test infrastructure. This is what I'm playing around with now:
This lets me acquire a boskos project which is great, but the only way to tell what project I've acquired is to look at the container logs, e.g.:
So even tho the boskos folks provided this sweet
boskosctl
image with a reasonablecmd
default, im gonna end up having to override the entrypoint and write a script (and hope that the image has bash in it!)The text was updated successfully, but these errors were encountered: