-
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
Unit Tests for Custom Task Retries #4686
Comments
/assign |
Hi @lbernick it is my first time writing an e2e test. I went through the custom task document and the e2e test file existing in the code base. And I want to sync with you about what I want to do and looking forward to your suggestion! I read the document Tekton runs and IBM introducing about custom task as well as the e2e retry test. I want to write an e2e test like e2e retry test and will first create the custom task controller and pipeline with ko and then check the run's status. I am not good at English now if there is any offence please tell me and forgive me. Thanks! |
Thanks so much @yuzp1996, I appreciate the enthusiasm! I know I said "test E2E in the original issue", but I think the best place here to start would be to add some more test coverage of custom task retries to the pipelinerun reconciler. This existing test case is the closest thing we currently have, but we could really use a test case that reconciles a pipelinerun with a custom task with retries, and verify that if the most recent attempt failed, the pipelinerun reconciler restarts the custom task if it has retries remaining (and does not restart the custom task if there are no retries remaining). If you'd like to also add E2E tests that run on a cluster, I would recommend against using the task-loops custom task controller you've linked. Instead, I think it would be useful to have a custom task controller that is meant just for testing. The controller could set the custom task status based on the custom task spec (or just set the status to succeeded to start). I think a controller like this would be generally useful for developers adding features to runs who want to test things out on their cluster. I'm at a conference this week but I am happy to help more next week if needed! Also feel free to contact me on the tekton slack. |
Thanks for your reply, your suggestion is very important to me. I will do as you suggest. If I need any help, I will try to contact you. Thanks again! |
All pipeline One option is to work with @afrittoli to enable custom configurations for these kind of tests where an Until we have |
@afrittoli @imjasonh Can we treat the tekton controller as a |
Do you mean have the standard Tekton controller also watch for At that point it might be easier just to write a simple external controller that watches |
@pritidesai I tend to agree with @imjasonh, and I don't really think it would make sense to make the main controller act as a custom task controller just for the tests (if we want to provide "default built-in" custom task, maybe we could do that, but even, it would probably make sense to extract it in another deployment). |
Created #5120 to track a custom Task controller; this issue can just be to track unit tests. |
/assign |
This comment summarizes the findings after digging into TEP-69 and checks the possibilities of test coverage improvement, suggesting that this can be closed.
Thanks to @lbernick for the guidance! |
Custom Task restries were added in #4327; however, some parts of the code base were missed and addressed in #4625 and #4647. We should test Custom Task retries E2E, fix any bugs if necessary, and increase our test coverage of this functionality.
The text was updated successfully, but these errors were encountered: