Skip to content

Windows tests fixing#6255

Closed
vlastahajek wants to merge 47 commits intoinfluxdata:masterfrom
bonitoo-io:vh-windows-tests-fixing
Closed

Windows tests fixing#6255
vlastahajek wants to merge 47 commits intoinfluxdata:masterfrom
bonitoo-io:vh-windows-tests-fixing

Conversation

@vlastahajek
Copy link
Copy Markdown
Contributor

Creating PR with intermediate fixes for various tests on Windows, reported in #3747, to validate fixes.

Required for all PRs:

@vlastahajek
Copy link
Copy Markdown
Contributor Author

I did first set of fixes for tests on Windows. I had to touch some internal components. Please, review.
More will come later.

SetupLogging(config)
log.Printf("E! TEST")
log.Printf("I! TEST") // <- should be ignored
log.Printf("I! TEST") // <- should be ignoredgo
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

typo


tags1 := map[string]string{
"path": "/",
"path": string(os.PathSeparator),
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Tell me a bit about this, we aren't actually running the plugin on the filesystem right? Why do we need to modify the path separators?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Generally, go filesystem related functions on Windows can take Unix style paths, but return Windows style (problem also for globpath).
And this line sets path with \.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Ahh, can we use "path": filepath.Clean("/") for these?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

filepath.Clean("/") could the work, but seems a bit magic on the places when we need to construct a OS specific file path.

return nil, nil, fmt.Errorf("exec: unable to parse command, %s", err)
var split_cmd []string
var err error
//cannot use shellquote.Split on Windows as it threats Windows path separator char '\' as a mark for backslashed special char
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Honestly, I love to remove shellquote completely and use a list of args on all platforms. That said I think this change has a high likelyhood of breaking existing config files.

I think instead we should skip associated failing tests in Windows and when -short is specified.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I don't understand.
When I had discovered this problem I was wondering how can be that exec plugin actually works for anyone on Windows. Only condition it can work now is that there is no path in the command.
How this fix would break existing config files?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

How this fix would break existing config files?

It come down to:

I was wondering how can be that exec plugin actually works for anyone on Windows

Anyone on Windows using this probably has a very precise command string here with unix style quoting. If the behavior is changed in anyway, it will break their config. The only way this wouldn't be true is if this 100% can't work at all in Windows.

Separate from this PR, we could add a new array based command option, similar to the exec output.


func init() {
if runtime.GOOS == "windows" {
LineSeparator = "\r\n"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This isn't really a Windows vs Unix thing, it's more about file encoding or terminal setup. I'd like to fix this more close to the tests themselves, not have this a package level item. I'll try to give more explanation by the instances where it is used.

Copy link
Copy Markdown
Contributor Author

@vlastahajek vlastahajek Sep 6, 2019

Choose a reason for hiding this comment

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

In tests, it is the matter of git checkout behavior. Default setting on Windows is that text files are converted.
What about adding this line the .gitattributes:
**/testdata/** test eol=lf
I tested that and it works smooth. I could just revert all related changes. It seems to be the best solution for this.
Only downside is that people, mainly Windows developers, have to aware of this and do not count with CRLF. Luckily, there is just a few pure Windows tests and they don't deal with line endings.

assert.Equal(t, internal.Size{Size: 1024 * 1024}, inputHTTPListener.MaxBodySize)
// Tests toml multiline basic strings.
assert.Equal(t, "/path/to/my/cert\n", inputHTTPListener.TLSCert)
assert.Equal(t, "/path/to/my/cert"+testutil.LineSeparator, inputHTTPListener.TLSCert)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We don't know what the line separator is, it depends on how git checked out the code. We should update this test to trim the string and then do the comparison. Elsewhere we should test that we can load a cert with either line ending.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Actually I originally did trimming here. But than I encountered the one bellow and changed that this way.


assert.NoError(t, err)
assert.Equal(t, "foo\n", string(out))
assert.Equal(t, "foo"+testutil.LineSeparator, string(out))
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I've mixed feelings on if these tests should just be deleted, but I see testing it proper would be a fair bit of work. We could instead run a command using the GO_WANT_HELPER_PROCESS method and then we can determine the line separator.

hasMeta: hasMeta(path),
HasSuperMeta: hasSuperMeta(path),
path: filepath.FromSlash(path),
path: path,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Will this change the style of the paths returned? If so this could be a breaking change and we need to be very careful. Please double and triple check the changes in this file.

Copy link
Copy Markdown
Contributor Author

@vlastahajek vlastahajek Sep 5, 2019

Choose a reason for hiding this comment

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

With fixing other test I had to make additional changes. All the fixes lead to the state where paths are always compared in the same form (forward slash as a path separator). It will not change any path returned

…paths must be in the same form (with slash as a path separator)
… dir and composing sock path using OS specific path separator char
@vlastahajek
Copy link
Copy Markdown
Contributor Author

I continued fixing rest of the tests to know what issues are there, still without a clean way how to properly deal with line and paths separators.
Now all tests finish either in success state or they are skipped because its feature is not available on Windows.
Let's continue by discussing specific issues.
I will update tests and clean git history when settled.

@danielnelson danielnelson added the fix pr to fix corresponding bug label Sep 5, 2019
@danielnelson
Copy link
Copy Markdown
Contributor

Can you also update the appveyor.yml to run more of the tests?

@vlastahajek
Copy link
Copy Markdown
Contributor Author

Done. All the short tests run now.

After discovering that Appveyor environment is bit different, mainly git is probably configured to do not convert line ending, I pushed proposed solution using a rule in main.gitattributes files, to force lf' line ending always.
Another fact on Windows is that AF_UNIX socket family is supported only since Windows 10 build 17063, so I made those test skipped on Windows generally.

@zak-pawel zak-pawel mentioned this pull request Nov 15, 2020
3 tasks
@sjwang90
Copy link
Copy Markdown
Contributor

PR #8414 covers more of this PR. A few tests (which will be still disabled after PR #8414 is merged) will need some changes in production code - some of the example of these changes are included in this PR.

We'll close this PR once those examples are included.

@sspaink
Copy link
Copy Markdown
Contributor

sspaink commented Mar 26, 2021

After #8414 has been closed, I think this can now be closed as well.

@sspaink sspaink closed this Mar 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

fix pr to fix corresponding bug platform/windows

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants