Skip to content

Allow fix tests to run concurrently #1576

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

Merged
merged 4 commits into from
Feb 20, 2021

Conversation

ashanbrown
Copy link
Contributor

@ashanbrown ashanbrown commented Dec 26, 2020

I noticed the "fix" tests were taking a while to run because they don't run concurrently. It would take about 12 seconds before and with this change takes about 4 on my local machine.

This change does two things:

  1. Ensures cleanup doesn't happen until after all tests are done.
  2. Disables use of the shared file lock.

I admittedly don't know what resources the shared file lock is designed to protect, but I suspect (2) is safe. This PR does not set t.Parallel() at the top-level of TestFix(). It would be nice to do that but again I don't know how that would play with disabling use of the file lock.

@ashanbrown ashanbrown added area: tests Continuous integration, tests and other checks feedback required Requires additional feedback labels Dec 26, 2020
@@ -27,7 +27,9 @@ func TestFix(t *testing.T) {
if os.Getenv("GL_KEEP_TEMP_FILES") == "1" {
t.Logf("Temp dir for fix test: %s", tmpDir)
} else {
defer os.RemoveAll(tmpDir)
t.Cleanup(func() {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

t.Cleanup waits for all tests to run, whereas defer does not.

@ashanbrown ashanbrown force-pushed the asb/parallel-fix-test branch 4 times, most recently from 872c5ac to e2fe6a3 Compare December 26, 2020 20:00
@@ -0,0 +1,12 @@
// +build go1.14
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not completely sure whether it's worth using build tags just to make this work but it is annoying how long the fix tests to run when doing development, so I think it's worth considering.

@ldez ldez self-requested a review December 26, 2020 21:20
@ldez
Copy link
Member

ldez commented Dec 26, 2020

I think that supporting the build of the project with an unmaintained version of Go is useless, encourages bad practice, and creates unnecessary complexity.

IMHO we can drop the support of go1.13, go1.16 will come soon so I think it's the right moment to drop go1.13.

@ashanbrown
Copy link
Contributor Author

@ldez I'd certainly be ok with deprecating go 1.13 and I agree it would be much cleaner than continuing to try to support go1.13. Given that it's a significant decision, I'd defer to @idenx or @ernado.

@ernado
Copy link
Member

ernado commented Dec 27, 2020

We can drop 1.13 support if it will really help us to simplify code.

I'd better wait until go1.16 if "hack" for 1.13 can be isolated and not overly complicates implementation.

@ernado ernado closed this Dec 27, 2020
@ernado
Copy link
Member

ernado commented Dec 27, 2020

Oops, wrong button, sorry

@ernado ernado reopened this Dec 27, 2020
@ashanbrown
Copy link
Contributor Author

I don't have a simpler hack than these build tags but I'm open to suggestions. I'm also happy to sit in this until go 1.16 is released in February.

@ernado
Copy link
Member

ernado commented Dec 27, 2020

Build tags are ok.

@ashanbrown
Copy link
Contributor Author

@ldez What's your take on this? Ok to merge for now or would you rather sit on this until go1.16 is released? I'm happy to patch it up once go1.16 is out. I could even put up a PR immediately and we could merge it in a few months.

@ernado
Copy link
Member

ernado commented Dec 27, 2020

Let's merge it and cleanup later. I've re-checked and 10-12 lines of version specific code is minor overhead.

Copy link
Member

@ernado ernado left a comment

Choose a reason for hiding this comment

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

LGTM

@ashanbrown
Copy link
Contributor Author

@ldez Do you have any concerns about merging this as is or would you rather we wait? As mentioned, I can put up a PR to clean this up immediately, to be merged when we stop supporting go 1.13.

Copy link
Member

@ldez ldez left a comment

Choose a reason for hiding this comment

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

For me, we can wait, but it's just my opinion.

@ashanbrown ashanbrown changed the title Allow fix tests to run concurrently WIP: allow fix tests to run concurrently Jan 2, 2021
ashanbrown and others added 4 commits February 19, 2021 19:52
Ensure cleanup doesn't happen until after all tests are done.
Also don't require holding a lock since files are not shared between tests.
@ldez ldez force-pushed the asb/parallel-fix-test branch from 32a6393 to 9606ad9 Compare February 19, 2021 20:51
@ldez ldez changed the title WIP: allow fix tests to run concurrently Allow fix tests to run concurrently Feb 19, 2021
@ldez ldez removed the feedback required Requires additional feedback label Feb 20, 2021
Copy link
Member

@ldez ldez left a comment

Choose a reason for hiding this comment

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

LGTM

@ldez ldez merged commit eace6a1 into golangci:master Feb 20, 2021
ashanbrown added a commit to ashanbrown/golangci-lint that referenced this pull request Feb 20, 2021
@ldez ldez added this to the v1.38 milestone Mar 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: tests Continuous integration, tests and other checks
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants