[android] Push test binaries w/o modifying executable name. #19960
Conversation
|
@drodriguez Just an FYI, JordanR is on vacation. |
At least test_rth.swift is checking the name of the executable during the test, so renaming every executable to __executable in Android will never work. Also, during the rth tool execution, all the results from before and after are pushed for every test. Since Android copies the passed files without relative paths, the library files will overwrite each other, making the test fail. Depends on swiftlang#19949 (more or less)
drodriguez
force-pushed
the
android-fix-test_rth
branch
from
ab69e7d to
c59e762
Compare
There was a problem hiding this comment.
I suppose that you might not remember why you renamed every binary to
__executable, but I think that since the arguments end up in the text files, the length of the binary name should not be that important anymore.
I do vaguely recall the length of a test's name causing issues, but it was a while ago, and I can't really remember. Assuming the same tests in the suite pass with this change, it seems like a straightforward improvement to me -- thanks for working on this! 👍
|
@swift-ci Please test |
|
Build failed |
|
Build failed |
…g#19960) At least test_rth.swift is checking the name of the executable during the test, so renaming every executable to __executable in Android will never work. Also, during the rth tool execution, all the results from before and after are pushed for every test. Since Android copies the passed files without relative paths, the library files will overwrite each other, making the test fail. Depends on swiftlang#19949 (more or less)
At least test_rth.swift is checking the name of the executable
during the test, so renaming every executable to __executable in
Android will never work.
Also, during the rth tool execution, all the results from before
and after are pushed for every test. Since Android copies the
passed files without relative paths, the library files will
overwrite each other, making the test fail.
Depends on #19949 (more or less)
@modocache: I suppose that you might not remember why you renamed every binary to
__executable, but I think that since the arguments end up in the text files, the length of the binary name should not be that important anymore. If you think it would be a problem, I might include an special case for the binaries pushed by the resilience tests (before_before,before_after,after_before,after_after).@jrose-apple: I had to limit the glob from only one of the directories (
beforeorafter). I don’t think this would break the test, or invalidate the testing results. When testingbefore, theafterdirectory would not be there, so trying to link against it would not find the library, failing the test. If you think this is not correct, I can try to modify #19949 to use relative paths, but it might get hairy.