-
Notifications
You must be signed in to change notification settings - Fork 1.8k
TEP-0090: Split up ResolvePipelineRunTask #4943
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
TEP-0090: Split up ResolvePipelineRunTask #4943
Conversation
|
The following is the coverage report on the affected files.
|
|
/test pull-tekton-pipeline-integration-tests |
a91fad6 to
9c40140
Compare
|
The following is the coverage report on the affected files.
|
|
/test pull-tekton-pipeline-alpha-integration-tests |
9c40140 to
ad78fc6
Compare
|
The following is the coverage report on the affected files.
|
ad78fc6 to
22f58f4
Compare
|
The following is the coverage report on the affected files.
|
22f58f4 to
f2ea856
Compare
|
The following is the coverage report on the affected files.
|
|
/test pull-tekton-pipeline-alpha-integration-tests there's a failure in is it a flake? but it's happened several times 😕 update: fixed in #4944 |
f2ea856 to
c1e7725
Compare
|
The following is the coverage report on the affected files.
|
|
/assign |
|
/retest |
|
/lgtm |
c1e7725 to
600802e
Compare
|
/lgtm |
|
The following is the coverage report on the affected files.
|
|
The following is the coverage report on the affected files.
|
|
/retest |
1877c04 to
8950ccf
Compare
|
/lgtm thank you @jerop 🎉 /test pull-tekton-pipeline-go-coverage I am sorry to bring this up again but please add unit tests while introducing any new function 🙏 |
|
The following is the coverage report on the affected files.
|
@pritidesai we have guidelines - https://github.com/tektoncd/community/blob/main/standards.md#tests - to write tests for exported functions only...there was no exported function added, all new functions are unexported functions that are used in the tested exported function (plus there is no functionality change)...or do we need to update that guideline? |
I think we should, what do you think? We (not intended to point on anyone) are adding a bunch of unexported functions which is great but its becoming very hard to read and understand the need of so many unexported functions. How are we sure that any changes we introduce are not breaking any functionality. This can only be made sure if we have 100% code coverage which is highly unlikely to maintain in any project. Also, our standards today says the code coverage must remain same (at least). But thats not something enforced by our CI. One such example - #4927 (comment) - Impacting code coverage by 5% while refactoring will burn us down in the future. |
8950ccf to
ea648f2
Compare
|
The following is the coverage report on the affected files.
|
that's one option, we could also try out the suggestion in the guidelines to move those functions into packages: "If you find yourself wanting to test an unexported function, consider whether it would make sense to move the test into another package and export it" added this topic to the agenda for the next Pipelines working group meeting on 06/14 (notes) so we can discuss with other maintainers
it'd be great if the CI enforced the code coverage standard, maybe for now we can add it to the submitter checklist to make it more explicit? we can bring it up in the working group meeting |
|
@abayer @pritidesai - rebased the PR to fix merge conflicts after #4942 got merged - please take a look |
ea648f2 to
6c80021
Compare
|
The following is the coverage report on the affected files.
|
Prior to this commit, the logic for resolving `TaskRun` and its and `Resources` needed for a given `PipelineTask` was included within the `ResolvePipelineRunTask` function. In this change, we split the logic into their own functions for reuse and readability. We also fix the names of `PipelineTask` variables to distinguish them from `Tasks`. No functional changes made in this commit.
6c80021 to
33d54c7
Compare
|
The following is the coverage report on the affected files.
|
|
/lgtm |
This suggestion can not be generalized, specially for the many complex packages we have in Pipelines. Unfortunately, it just resulting in a smelly code.
I am not pointing at you @jerop, thanks for your understanding ❤️ Also, thank you for adding it to the WG for further discussion. Didn't expect this to be merged as is, we have many functions with similar (complex) signatures now. At the same time, excited to see this result in much more meaningful and reusable code with matrix 🎉 pipeline/pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go Lines 448 to 564 in 566e2e3
|
Changes
Prior to this commit, the logic for resolving
TaskRunandResourcesneeded for a givenPipelineTaskwas included within theResolvePipelineRunTaskfunction.In this change, we split the logic into their own functions for reuse and readability. We also fix the names of
PipelineTaskvariables to distinguish them from
Tasks.No functional changes made in this commit.
/kind feature
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
Release Notes