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

TaskRun should have Results in Status #146

Closed
bobcatfish opened this issue Oct 12, 2018 · 7 comments · Fixed by #292
Closed

TaskRun should have Results in Status #146

bobcatfish opened this issue Oct 12, 2018 · 7 comments · Fixed by #292
Assignees
Labels
meaty-juicy-coding-work This task is mostly about implementation!!! And docs and tests of course but that's a given

Comments

@bobcatfish
Copy link
Collaborator

Expected Behavior

When TaskRun executes, it will upload its logs and results to the locations in PipelineParams. A user should be able to look at the Status of a TaskRun and see exactly where those logs ended up (i.e. the whole path).

This path should be determined by the controller, e.g. a folder in the path named after the TaskRun and/or timestamp, and provided in the Status of the TaskRun.

Actual Behavior

The TaskRun Spec (not Status!) has Results which in a previous iteration of our examples were expected to be provided manually:

https://github.com/knative/build-pipeline/blob/dcc2cb189f268c1a9651499c1c1f6ce5f76b1e02/examples/invocations/run-kritis-test.yaml#L24-L36

I deleted this from the example b/c I was thinking that referencing the PipelineParams was enough.

Additional Info

Note #107 is about actually making this work, this is more about the API.

@bobcatfish bobcatfish added the meaty-juicy-coding-work This task is mostly about implementation!!! And docs and tests of course but that's a given label Oct 12, 2018
@bobcatfish
Copy link
Collaborator Author

Note after discussing with @shashwathi , we should keep the results in spec as well, so we need both, e.g.

spec:
 results: 
     runs: 
       name: 'runsBucket' 
       type: 'gcs' 
       url: 'gcs://somebucket/results/runs' 
     logs: 
       name: 'logBucket' 
       type: 'gcs' 
       url: 'gcs://somebucket/results/logs' 
     tests: 
       name: 'testBucket' 
       type: 'gcs' 
       url: 'gcs://somebucket/results/tests' 
status:
 results: 
     runs: 
       name: 'runsBucket' 
       type: 'gcs' 
       url: 'gcs://somebucket/results/runs/mytaskrun/' 
     logs: 
       name: 'logBucket' 
       type: 'gcs' 
       url: 'gcs://somebucket/results/logs/mytaskrun' 
     tests: 
       name: 'testBucket' 
       type: 'gcs' 
       url: 'gcs://somebucket/results/tests/mytaskrun' 

(This task is just about adding the fields to Status, not about implementing the logic)

@tejal29
Copy link
Contributor

tejal29 commented Oct 30, 2018

Related to #107

@tanner-bruce
Copy link

This task is just about adding the fields to Status, not about implementing the logic

@bobcatfish does that mean this task is only about adding the results struct into the status struct, but not actually doing anything with the new field? This ticket seems deceptively simple

@bobcatfish
Copy link
Collaborator Author

@bobcatfish does that mean this task is only about adding the results struct into the status struct, but not actually doing anything with the new field? This ticket seems deceptively simple

lol yes - @aaron-prindle was asking me the same question - I'm beginning to this I should have just implemented this instead of writing up this ticket about it XD

@bobcatfish
Copy link
Collaborator Author

Since this is such a sad small Task, I'm going to just assign it to myself and do it XD

@bobcatfish
Copy link
Collaborator Author

I'm going to just assign it to myself and do it XD

She says 21 days ago an then does nothing XD

@bobcatfish
Copy link
Collaborator Author

Note Runs and Tests were removed in #282

bobcatfish added a commit to bobcatfish/pipeline that referenced this issue Dec 1, 2018
When a user kicks off a run, they will provide an endpoint to upload
logs to (initial implementation will be in #107). The corresponding
fields in `status` will indicate where the logs actually got uplaoded
to.

Once we actually get to #107, and especially once we start supporting
endpoints other than GCS, we may find this isn't useful and remove it.

Fixes tektoncd#146
bobcatfish added a commit to bobcatfish/pipeline that referenced this issue Dec 1, 2018
When a user kicks off a run, they will provide an endpoint to upload
logs to (initial implementation will be in #107). The corresponding
fields in `status` will indicate where the logs actually got uplaoded
to.

Once we actually get to #107, and especially once we start supporting
endpoints other than GCS, we may find this isn't useful and remove it.

Fixes tektoncd#146
bobcatfish added a commit to bobcatfish/pipeline that referenced this issue Dec 1, 2018
When a user kicks off a run, they will provide an endpoint to upload
logs to (initial implementation will be in #107). The corresponding
fields in `status` will indicate where the logs actually got uplaoded
to.

Once we actually get to #107, and especially once we start supporting
endpoints other than GCS, we may find this isn't useful and remove it.

Fixes tektoncd#146
bobcatfish added a commit to bobcatfish/pipeline that referenced this issue Dec 1, 2018
When a user kicks off a run, they will provide an endpoint to upload
logs to (initial implementation will be in #107). The corresponding
fields in `status` will indicate where the logs actually got uplaoded
to.

Once we actually get to #107, and especially once we start supporting
endpoints other than GCS, we may find this isn't useful and remove it.

Fixes tektoncd#146
bobcatfish added a commit to bobcatfish/pipeline that referenced this issue Dec 1, 2018
When a user kicks off a run, they will provide an endpoint to upload
logs to (initial implementation will be in #107). The corresponding
fields in `status` will indicate where the logs actually got uplaoded
to.

Once we actually get to #107, and especially once we start supporting
endpoints other than GCS, we may find this isn't useful and remove it.

Fixes tektoncd#146
knative-prow-robot pushed a commit that referenced this issue Dec 4, 2018
When a user kicks off a run, they will provide an endpoint to upload
logs to (initial implementation will be in #107). The corresponding
fields in `status` will indicate where the logs actually got uplaoded
to.

Once we actually get to #107, and especially once we start supporting
endpoints other than GCS, we may find this isn't useful and remove it.

Fixes #146
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meaty-juicy-coding-work This task is mostly about implementation!!! And docs and tests of course but that's a given
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants