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: better resource cleanup handling #419

Merged
merged 7 commits into from
Dec 8, 2022

Conversation

eddycharly
Copy link
Contributor

What this PR does / why we need it:

This PR improves resource cleanup handling.

  • moves cleanup code closer to the resource creation code
  • reuse discovery information used at resource creation time to make creation/cleanup more robust
  • only cleanup a resource if kuttl created it (don't register cleanup if it was an update)

Signed-off-by: Charles-Edouard Brétéché <charles.edouard@nirmata.com>
pkg/test/case.go Outdated
@@ -355,7 +344,7 @@ func (t *Case) Run(test *testing.T, tc *report.Testcase) {
tc.Assertions += len(testStep.Asserts)
tc.Assertions += len(testStep.Errors)

if errs := runStep(test, t, testStep, ns); len(errs) > 0 {
if errs := testStep.Run(test, ns.Name, t.SkipDelete); len(errs) > 0 {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could it make sense to add a new SkipDelete field to the Step struct, to avoid passing this around as a func param?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure it would make things better, currently this is not overridable in a Step, this makes sense to me that it is the responsibility of the caller to pass the flag.
I don't have a strong opinion though, if you prefer the field based approach I will use that.
WDYT ?

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't have a strong opinion on this. So far the func has few params. What I don't like is funcs with a lot of params - especially of the same type. :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Switched to a struct field.

pkg/test/step.go Outdated Show resolved Hide resolved
Signed-off-by: Charles-Edouard Brétéché <charles.edouard@nirmata.com>
@eddycharly eddycharly requested review from erikgb and removed request for kensipe, kaiwalyajoshi and asekretenko November 14, 2022 09:18
Signed-off-by: Charles-Edouard Brétéché <charles.edouard@nirmata.com>
pkg/test/step.go Outdated Show resolved Hide resolved
Signed-off-by: Charles-Edouard Brétéché <charles.edouard@nirmata.com>
Copy link
Contributor

@erikgb erikgb left a comment

Choose a reason for hiding this comment

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

\lgtm

Copy link
Member

@kensipe kensipe left a comment

Choose a reason for hiding this comment

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

integration tests need updating for completion

./bin/golangci-lint --timeout 5m run --build-tags integration
pkg/test/step_integration_test.go:443:28: not enough arguments in call to step.Run
	have (string)
	want (*"testing".T, string) (typecheck)
	errs := step.Run(namespace)
	                          ^
pkg/test/step_integration_test.go:461:33: not enough arguments in call to step.Run
	have (string)
	want (*"testing".T, string) (typecheck)
	errors := step.Run("irrelevant")
	                               ^
pkg/test/step_integration_test.go:479:33: not enough arguments in call to step.Run
	have (string)
	want (*"testing".T, string) (typecheck)
	errors := step.Run("irrelevant")

@kensipe
Copy link
Member

kensipe commented Nov 14, 2022

for awareness... I commonly run the following as a starting point of review: make lint test integration-test

make lint is failing at this point. Likely missed based on the integration build tag

@eddycharly
Copy link
Contributor Author

eddycharly commented Nov 14, 2022

I will fix this tomorrow. How about running this in a gh workflow ?

@kensipe
Copy link
Member

kensipe commented Nov 14, 2022

yeah... when I noticed the passing CI... I had the same thought. I will look into that.

@kensipe
Copy link
Member

kensipe commented Nov 14, 2022

well... now I remember some issues we had in the past but haven't been resolved. For some reason CircleCI wouldn't run PRs from non-committers. So the full CI isn't run (just the DCO). I worked with circle to help resolve that but didn't get it resolved. We were looking to move to Github Actions in part to solve that... but it also reduces the number of CI dependencies. Probably need to refocus on that.

@kensipe
Copy link
Member

kensipe commented Nov 14, 2022

that's what #337 was intended to solve.

Copy link
Member

@kensipe kensipe left a comment

Choose a reason for hiding this comment

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

thanks @eddycharly . I pushed the integration test refactors. I'll merge after good CI runs. Thanks for the contribution!

@kensipe kensipe merged commit d3efc8a into kudobuilder:main Dec 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants