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

[refactor] Remove ImplicitParamEnabled context. #4528

Merged
merged 1 commit into from
Feb 9, 2022

Conversation

wlynch
Copy link
Member

@wlynch wlynch commented Jan 27, 2022

Changes

This change does not introduce any different behavior - it refactors the
code to remove the use of the ImplicitParamEnabled context in favor of
direct function calls.

/kind cleanup

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

  • Docs included if any changes are user facing
  • Tests included if any functionality added or changed
  • Follows the commit message standard
  • Meets the Tekton contributor standards (including
    functionality, content, code)
  • Release notes block below has been filled in or deleted (only if no user facing changes)

Release Notes

NONE

This change does not introduce any different behavior - it refactors the
code to remove the use of the ImplicitParamEnabled context in favor of
direct function calls.
@tekton-robot tekton-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. labels Jan 27, 2022
@tekton-robot tekton-robot added the size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. label Jan 27, 2022
@wlynch
Copy link
Member Author

wlynch commented Jan 27, 2022

/cc @jerop

@tekton-robot tekton-robot requested a review from jerop January 27, 2022 16:28
@tekton-robot
Copy link
Collaborator

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/apis/pipeline/v1beta1/param_context.go 98.4% 96.3% -2.1
pkg/apis/pipeline/v1beta1/pipelinerun_defaults.go 94.1% 93.3% -0.8
pkg/apis/pipeline/v1beta1/task_defaults.go 83.3% 80.0% -3.3

Copy link
Collaborator

@bobcatfish bobcatfish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i have a couple of comments about the tests - in particular im not clear on what the intention is of the TestImplicitParams_Pipeline test when that defaulting logic shouldn't include the implicit params logic (maybe it's just a naming or commenting thing to clear that up, but im thinking more focused tests might help here)

but in the meantime this has been open for a while and think the codebase is in a better place with this PR in (i.e. more explicit than it was when we were using flags in the context variable to change function behavior) so id like to see this get in even without those tweaks (if needed at all)

/approve
/lgtm

@@ -314,160 +297,53 @@ func TestImplicitParams_Pipeline(t *testing.T) {

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im a bit confused about why the Pipeline spec has an implicit params test - it seems like in the updated version, the implicit params logic is only called from the pipelinerun and taskrun defaulting functions - i would think pipeline.SetDefaults wouldn't have any implicit param logic? (unless the purpose of this test is to ensure that the implicit params logic is not applied?)

one thing that might make this a bit clearer is to have test cases specifically for the new implicit params functions as well - the current test cases seem to be covering the existing defaulting logic as well so it's a bit hard to tell what is being caused by the implicit params logic and what is caused by the defaulting logic

for _, tc := range []struct {
// Expect in and want to be the same type.
in apis.Defaultable
want interface{}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you include a name to indicate the purpose of each test case? i think its one for a pipelinerun, one for a taskrun (and i think nothing more complicated than that?) but it wasnt easy to tell without reading through each test case

@tekton-robot tekton-robot added the lgtm Indicates that a PR is ready to be merged. label Feb 9, 2022
@tekton-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bobcatfish

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@tekton-robot tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 9, 2022
@tekton-robot tekton-robot merged commit 6b72412 into tektoncd:main Feb 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. lgtm Indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants