-
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
Complete implementation of image pull failure handling #4952
Complete implementation of image pull failure handling #4952
Conversation
Signed-off-by: Sascha Schwarze <schwarzs@de.ibm.com>
Hi @SaschaSchwarze0. Thanks for your PR. I'm waiting for a tektoncd member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
If somebody has a hint where the problem with my release note block is, let me know. |
@SaschaSchwarze0 you need to remove the space between the backticks and release-note |
Thanks, no idea how that could have gotten in there. lol |
/ok-to-test |
The following is the coverage report on the affected files.
|
/retest |
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 @SaschaSchwarze0 🎉
Please add the context that you have in the pull request description to the commit message as well: https://github.com/tektoncd/community/blob/main/standards.md#commits
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jerop 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 |
/test pull-tekton-pipeline-integration-tests |
Thank you @SaschaSchwarze0 This looks good to me. |
`tr.Status.TaskSpec.Steps` can be out-of-sync with `tr.Status.Steps`. As we already have the image information (through `ImageID`) in the struct be are getting from our iteration, we don't need to look into another array, with the risk of getting a panic. The same goes for sidecars. We managed to get multiple panics on the controller prior to this change. See tektoncd#4952 for the initial implementation. Signed-off-by: Vincent Demeester <vdemeest@redhat.com>
`tr.Status.TaskSpec.Steps` can be out-of-sync with `tr.Status.Steps`. As we already have the image information (through `ImageID`) in the struct be are getting from our iteration, we don't need to look into another array, with the risk of getting a panic. The same goes for sidecars. We managed to get multiple panics on the controller prior to this change. See tektoncd#4952 for the initial implementation. Signed-off-by: Vincent Demeester <vdemeest@redhat.com>
`tr.Status.TaskSpec.Steps` can be out-of-sync with `tr.Status.Steps`. As we already have the image information (through `ImageID`) in the struct be are getting from our iteration, we don't need to look into another array, with the risk of getting a panic. The same goes for sidecars. We managed to get multiple panics on the controller prior to this change. See tektoncd#4952 for the initial implementation. Signed-off-by: Vincent Demeester <vdemeest@redhat.com>
`tr.Status.TaskSpec.Steps` can be out-of-sync with `tr.Status.Steps`. As we already have the image information (through `ImageID`) in the struct be are getting from our iteration, we don't need to look into another array, with the risk of getting a panic. The same goes for sidecars. We managed to get multiple panics on the controller prior to this change. See #4952 for the initial implementation. Signed-off-by: Vincent Demeester <vdemeest@redhat.com>
`tr.Status.TaskSpec.Steps` can be out-of-sync with `tr.Status.Steps`. As we already have the image information (through `ImageID`) in the struct be are getting from our iteration, we don't need to look into another array, with the risk of getting a panic. The same goes for sidecars. We managed to get multiple panics on the controller prior to this change. See tektoncd#4952 for the initial implementation. Signed-off-by: Vincent Demeester <vdemeest@redhat.com>
`tr.Status.TaskSpec.Steps` can be out-of-sync with `tr.Status.Steps`. As we already have the image information (through `ImageID`) in the struct be are getting from our iteration, we don't need to look into another array, with the risk of getting a panic. The same goes for sidecars. We managed to get multiple panics on the controller prior to this change. See tektoncd#4952 for the initial implementation. Signed-off-by: Vincent Demeester <vdemeest@redhat.com>
`tr.Status.TaskSpec.Steps` can be out-of-sync with `tr.Status.Steps`. As we already have the image information (through `ImageID`) in the struct be are getting from our iteration, we don't need to look into another array, with the risk of getting a panic. The same goes for sidecars. We managed to get multiple panics on the controller prior to this change. See #4952 for the initial implementation. Signed-off-by: Vincent Demeester <vdemeest@redhat.com>
`tr.Status.TaskSpec.Steps` can be out-of-sync with `tr.Status.Steps`. As we already have the image information (through `ImageID`) in the struct be are getting from our iteration, we don't need to look into another array, with the risk of getting a panic. The same goes for sidecars. We managed to get multiple panics on the controller prior to this change. See #4952 for the initial implementation. Signed-off-by: Vincent Demeester <vdemeest@redhat.com>
`tr.Status.TaskSpec.Steps` can be out-of-sync with `tr.Status.Steps`. As we already have the image information (through `ImageID`) in the struct be are getting from our iteration, we don't need to look into another array, with the risk of getting a panic. The same goes for sidecars. We managed to get multiple panics on the controller prior to this change. See tektoncd#4952 for the initial implementation. Signed-off-by: Vincent Demeester <vdemeest@redhat.com>
Signed-off-by: Sascha Schwarze schwarzs@de.ibm.com
Changes
I was a little confused by the code flow from #4921. A
checkPodFailed
function that then always setTaskRunReasonImagePullFailed
in case of an error looked incorrect.So, I am doing what I think @abayer referred to in #4921 (comment) = adding the reason to the return values of the function.
Also putting in what @imjasonh asked for in #4921 (comment) = the step name and the image into the message.
Finally, I am adding the missing sidecar handling.
/kind feature
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
(if there are no user facing changes, use release note "NONE")
Release Notes