-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
lntest: allow the main test files to be buildable w/o the rpctest build tag #4593
Conversation
387cb11
to
eaf63d0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will be nice to finally get this in, LGTM 🎉
.travis.yml
Outdated
- make lint workers=1 | ||
# Step 3: Lint go code. Limit to 1 worker and invoke GC more often to | ||
# reduce memory usage. | ||
- GOGC=20 make lint workers=1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it OOM on travis because of the increased number of lines to lint?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. And if I look at GitHub Actions, it uses more than 8GB of RAM there when not restricted. As the lint on Travis only acts as a gatekeeper to prevent non-linted code to block our build queues, maybe it would make sense to exclude the itest
directory there to speed things up? Or maybe there's a way to just include lines changed in the PR? I'll investigate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, restricting only to the commits of a PR doesn't speed things up. The linter will still analyze everything but only report problems added in the specified commits. I think excluding some directories might be the way to go. Or we just accept the 3 minutes this takes before each Travis run.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think that is okay. I would be interested to see if we could increase the number of workers on Travis though, as that would most likely be the way to speed it up (if it doesn't OOM)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, good idea. If we can limit the amount of memory used through the environment variables, we should be able to increase the worker count again.
I looked it up on the Travis spec page and apparently the VMs have 7.5GB. I'm trying with GTOGC=50
and no worker limit which resulted in 6.3GB being used on my machine. Let's see if it OOMs with that on Travis or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good:
$ GOGC=50 make lint
...
INFO Memory: 396 samples, avg is 3384.2MB, max is 4855.0MB
INFO Execution took 1m40.098082206s
eaf63d0
to
ba2adb9
Compare
@guggero nice work in reviving this! needs a quick rebase then ready to go! |
ba2adb9
to
874d611
Compare
Rebased. |
Needs another :) |
874d611
to
bf5dfe2
Compare
Rebased. If I had two green checkmarks, I could merge once all CI check pass ;-) |
bf5dfe2
to
91e9fb1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👏
This in prep for a bigger move in the next commit.
Otherwise, if we remove the build tags, then there's no default backend, and compilation will fail.
…ld tag In this commit, we modify our build tag set up to allow the main test files to be buildable w/o the current rpctest tag. We do this so that those of us that use extensions which will compile live files like vim-go can once again fix compile errors as we go in our editors. In order to do this, we now make an external `testsCases` variable, and have two variants: one that's empty (no build tag), and one that's fully populated with all our tests (build tag active). As a result, the main file will now always build regardless of if the build tag is active or not, but we'll only actually execute tests if the `testCases` variable has been populated. As sample run w/ the tag off: ``` === RUN TestLightningNetworkDaemon --- PASS: TestLightningNetworkDaemon (0.00s) PASS ok github.com/lightningnetwork/lnd/lntest/itest 0.051s ```
We fix all linter issues except for the 'lostcontext' and 'unparam' ones as those are too numerous and would increase the diff even more. Therefore we silence them in the itest directory for now. Because the linter is still not build tag aware, we also have to silence the unused and deadcode sub linters to not get false positives.
To make it possible to compile the itests together with the other tests, we don't want to use anything from the optional subservers.
There is a setting to control how often the garbage collector is run. Apparently this is a tradeoff between CPU and memory usage. If we can limit the memory being used in that way, this allows us to use multiple worker again, so overall this shouldn't be much slower than before.
91e9fb1
to
1558edb
Compare
Last linter run ended in OOM, reduced the |
Super happy to see this finally land! |
This is the revival of #3382 originally created by @Roasbeef. I'm taking this over, I hope you don't mind.
In this PR, we modify our build tag set up to allow the main test
files to be buildable w/o the current rpctest tag. We do this so that
those of us that use extensions which will compile live files like
vim-go can once again fix compile errors as we go in our editors.
In order to do this, we now make an external
testsCases
variable, andhave two variants: one that's empty (no build tag), and one that's fully
populated with all our tests (build tag active). As a result, the main
file will now always build regardless of if the build tag is active or
not, but we'll only actually execute tests if the
testCases
variablehas been populated.
As sample run w/ the tag off: