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

DEVPROD-7742 Fix current testifylint lint issues (manual) #8604

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

ZackarySantana
Copy link
Contributor

@ZackarySantana ZackarySantana commented Jan 8, 2025

DEVPROD-7742

Description

Before merging in the fix for our linter and adding stricter rules, I'm doing smaller PRs to fix the current mistakes that our linter should be catching.

This PR fixes the testifylint lint issues with manual changes. There weren't that many that autofix didn't fix, but these were the most valuable as it caught some bugs (e.g. we were panicing in some goroutines by using require in them, we also had an accidental assert.Zero(t, 0, <actual_variable>.... so it always passed since it was asserting on the constant 0).

This PR does not add the testifylint to our linters yet, this is blocked on upgrading our go version. The corresponding ticket is DEVPROD-13938.

Testing

Running golangci-lint run in my terminal results in no more lint errors. This pulls from the .golangci.yml file's configuration (which our linter task should be doing.

@ZackarySantana ZackarySantana requested a review from a team January 8, 2025 20:57
@ZackarySantana ZackarySantana self-assigned this Jan 8, 2025
@@ -425,6 +425,7 @@ func TestGetResolvedPlannerSettings(t *testing.T) {
// Fallback to the SchedulerConfig.ExpectedRuntimeFactor as PlannerSettings.ExpectedRunTimeFactor is equal to 0.
assert.EqualValues(t, 7, resolved0.ExpectedRuntimeFactor)
assert.EqualValues(t, 20, resolved0.GenerateTaskFactor)
//nolint:testifylint // We expect it to be exactly 10.
Copy link
Contributor

@Kimchelly Kimchelly Jan 10, 2025

Choose a reason for hiding this comment

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

Out of curiosity, what does testifylint not like about this + the others? It seems like checking that some output value exactly matches an expected hard-coded value would be a normal thing to do in a test.

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.

2 participants