-
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
Dereference the TaskSpec into TaskRun.Status. #2444
Conversation
Nice, I was going to work on this after I finished #2421 :) One though I have is that we should also store resources in the status. |
/test pull-tekton-pipeline-integration-tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this!
I have one comment on this.
Even if only use it for audit for now, I would still add the task to the status when we first obtain the task
pkg/pod/status.go
Outdated
@@ -116,6 +118,12 @@ func MakeTaskRunStatus(logger *zap.SugaredLogger, tr v1alpha1.TaskRun, pod *core | |||
trs.Steps = []v1alpha1.StepState{} | |||
trs.Sidecars = []v1alpha1.SidecarState{} | |||
|
|||
ts := v1beta1.TaskSpec{} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might want to store this into the TaskRun status when we first fetch it, i.e.
pipeline/pkg/reconciler/taskrun/taskrun.go
Lines 207 to 208 in 9344e4f
getTaskFunc, kind := c.getTaskFunc(tr) | |
taskMeta, taskSpec, err := resources.GetTaskData(ctx, tr, getTaskFunc) |
We could then modify that could to fetch the task only if not available in the status, and else use that from status
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoa, yeah thanks. Do you think it's enough to only set this once, the first time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think that would be great! Especially when the task spec is not embedded in the taskrun spec, this avoids issues when the task definition is updated during the run.
The only case where is use the change to the spec for something is cancel
, so we would have to find an alternative for that. Perhaps the tkn
client could reset the task definition in status to force a reload? @vdemeester what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, actually it would not break cancel
since that goes in the spec of the taskrun, not of the task - so fetching the task only once would work just fine!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah
I hesitated on this one for now. We get some of the resource info in the status now (under containers): {
"container": "step-git-source-skaffold-git-build-push-kaniko-p28nk",
"imageID": "docker-pullable://gcr.io/dlorenc-vmtest2/git-init-4874978a9786b6625dd8b6ef2a21aa70@sha256:99f410cc098b4300384ad056c8febf5bb79e4749417b5e9621fc529514c4a0c3",
"name": "git-source-skaffold-git-build-push-kaniko-p28nk",
"terminated": {
"containerID": "docker://b96396af17dea856526547ef5e140478148d4d672c8bda8a95e6010380e7cfab",
"exitCode": 0,
"finishedAt": "2020-04-20T15:32:20Z",
"message": "[{\"key\":\"commit\",\"value\":\"6ed7aad5e8a36052ee5f6079fc91368e362121f7\",\"resourceRef\":{\"name\":\"skaffold-git-build-push-kaniko\"}}]",
"reason": "Completed",
"startedAt": "2020-04-20T15:32:18Z"
}
}, This doesn't include commands/arguments, but it's close. We also get Should we add them to the v1beta1 API, given we don't know the future of them yet? #2447 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
|
1f9c107
to
12304b5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this!
We should do the same for pipelines :)
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: afrittoli The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
9ff346b
to
b6cedcb
Compare
fb4ddc3
to
5cff4f6
Compare
``` | ||
kubectl get taskrun <name> | ||
``` | ||
The exact Task Spec used to instantiate the TaskRun is also included in the Status for full auditability. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
/test pull-tekton-pipeline-build-tests |
The Task definition used for a TaskRun can change after the TaskRun has started. This poses problems for auditability post-run. Rather than chase down every part of a Task that we might like to audit later, let's just add the entire thing here. This is a replacement for tektoncd#2399
/test pull-tekton-pipeline-integration-tests |
/lgtm |
/test pull-tekton-pipeline-integration-tests |
Yep. Apart from my own selfish utility concerns ;) size in etcd is the only real concern. This is still fairly safe and not going to break anything for us. |
/test pull-tekton-pipeline-integration-tests |
/test pull-tekton-pipeline-build-tests |
The Pipeline definition used for a PipelineRun can change after the PipelineRun has started. This poses problems for auditability post-run. Rather than chase down every part of a Pipeline that we might like to audit later, let's just add the entire thing here. This is a follow up to tektoncd#2444.
The Pipeline definition used for a PipelineRun can change after the PipelineRun has started. This poses problems for auditability post-run. Rather than chase down every part of a Pipeline that we might like to audit later, let's just add the entire thing here. This is a follow up to tektoncd#2444.
The Pipeline definition used for a PipelineRun can change after the PipelineRun has started. This poses problems for auditability post-run. Rather than chase down every part of a Pipeline that we might like to audit later, let's just add the entire thing here. This is a follow up to tektoncd#2444.
The Pipeline definition used for a PipelineRun can change after the PipelineRun has started. This poses problems for auditability post-run. Rather than chase down every part of a Pipeline that we might like to audit later, let's just add the entire thing here. This is a follow up to #2444.
Changes
The Task definition used for a TaskRun can change after the TaskRun
has started. This poses problems for auditability post-run. Rather
than chase down every part of a Task that we might like to audit later,
let's just add the entire thing here.
This is a replacement for #2399
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide for more details.
Double check this list of stuff that's easy to miss:
cmd
dir, please updatethe release Task to build and release this image.
Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes