-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Websocket derp test fixes #2247
Conversation
…ailscale head integration testing: comply with linter
…s for tailscale head integration testing: tsic.New must never return nil
… options for tailscale head
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.
two nits, otherwise good
integration/embedded_derp_test.go
Outdated
err = s.CreateTailscaleIsolatedNodesInUser( | ||
hash, | ||
userName, | ||
"all", | ||
"head", |
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.
This can be the VersionHead
constant you added
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.
Good idea, I probably missed this instance because I only looked at the linter output when I introduced that constant.
// This option is only meaningful when invoked on **HEAD** versions of the client. | ||
// Attempts to use it with any other version is a bug in the calling code. | ||
func WithBuildTag(tag string) Option { | ||
return func(tsic *TailscaleInContainer) { |
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.
I propose panicking here if the tsic passed is not HEAD
, just to fail fast so the dev can fix it without faffing around.
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.
Done, for now I have opted to panic with the same error value I return from the other checks.
At this point I think it might be safe to remove the build tags check here, but since I wrote it to be generic and check for any build time config, it may still catch mistakes on future build options. I am not against removing it if desired, though.
Thanks! |
Fixes #2241